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■ EX  ECU 1 IV £ SUMMAKY 


A.  PURPOSE 


The  purpose  cf  this  study  is  to  asse 
Large  Scale  Integration  (LSI)  of  electronic 
respect  to  future  airborne  digital  system 
findings  are  applicable  to  any  airborne  syst 
this  study  is  the  VSTOL  aircraft  projected 
and  production  in  the  1985  time  frame. 


ss  the  impact  of 
circuits  with 
s.  Although  the 
em,  the  focus  of 
for  development 


E.  SCOPE 


The  study  addresses  the  design,  implementation,  testing, 
servicing  ana  the  associated  life  cycle  costs  of  airborne 
digital  computer  systems,  both  the  hardware  and  the  programs 
necessary  for  successful  operation  of  the  system.  The  scope 
cf  the  study  is  limited  strictly  to  the  digital  computer 
systems  and  does  not  include  the  sensors,  which  provide  the 
data,  the  displays,  keyboards,  and  switches  which  provide 
the  human  interface,  or  the  effectors  whicn  help  carry  out 
the  actions  of  the  system. 


FAME 
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C.  OhJEClIVE 

The  study  provides  in  for  cation  for  decision  making  on 
the  future  course  of  action  in  the  highly  volatile 
electronic  circuit  industry.  The  study  also  provides  a 
design  phi  csosphy,  an  analysis  methodology  useful  for 
program  design,  and  a life  cycle  cost  analysis  irethod 
applicable  tc  similar  studies. 

C.  METHCE  OF  APPROACH 

The  study  first  explores  the  implications  of  tae 
technological  changes  which  are  brougnt  about  by  Large  Scale 
Integration.  Although  the  technological  changes  relate  to 
nardware,  these  changes  imply  corresponding  changes  in 
system  architectures  and  programming.  One  of  the  most 
important  cost  components  is  the  software  design.  The  study 
describes  a set  of  software  design  principles  which 
emphasises  uniformity,  homogeneity,  and  a testable  design. 
Ihe  design  principles  are  applicaole  particularly  to 
tactical  systems  which  are  known  to  be  complex  and  difficult 
tc  test. 

We  separate  the  software  design  from  hardware 
implementation.  The  software  design  can  be  carried  out 
without  committment  to  a specific  computer  hardware.  The 
operational  programs  can  be  developed  ar.d  tested  on 
developmental  systems  which  are  specifically  suited  fer 
program  development. 

Software  design,  implementation  and  testing  is  a time 

Id 


consuming  process  and  in  major  systems  takes  years  to 
d e ve 1 op • Decision?  on  which  computer  hardware  to  use  can  be 
mad*  at  a point  in  time  near  the  end  or  the  development 
cycle.  Ihit  insures  an  up-to-date  hardware  imp lent ntat ion 
and  an  improved  transferability  ct  sottwaLe  products. 

i Je  see  two  major  trends  in  airborne  system's 
architectures.  These  alternatives  fcr  hardware 
1 mplementaticn  du:  the  homoqeneous  ana  the  heterogeneous 
systems.  lat  homogeneous  system  consists  or  a collection  of 
computers  each  ot  which  is  functionally  identical.  The 
het  eroqeneous  systems  contain  at  least  two  functionally 
different  types  or  computers:  the  "mission  computers"  and 
the  "embedded"  computers. 

In  order  to  develop  a life  cycle  cost  analysis  fcr  t.ie 
two  major  design  alternatives,  we  first  develop  the 
projected  functional  requirements  tor  the  VSl'OL  (attack 
version)  tactical  system.  because  the  functional 
requirements  of  VSTOl  will  be  similar  to  the  presently 
operational  attack  aircraft,  As-ii,  we  study  the  A n-R  in 
great  detail.  From  the  detailed  data  wo  can  estimate  verst 
case  execution  times,  the  number  ot  variables  shared  by 
processes,  the  number  of  instructions,  constants  and 
variables  in  the  programs.  by  knowing  the  execution  times 
toi  particular  instructions  on  a given  computer,  we  can 
estimate  the  execution  tim«s  ot  program  segments  executed  on 
that  computer. 

From  thi'  data  we  can  compare  the  homogeneous  and 
het oioqen*out  implementation  alternatives  tor  the  An-R,  or 
to;  a projected  system  such  as  the  VSTOl  . The  lite  cycle 
cost  I'iitriitt  is  developed  for  the  alternatives. 

based  on  the  analysis  ot  the  Ao-fc  system,  it  is 
established  that  pr  sently  marketed  LSI  computers  can  be 


is 


used  to  lapiemcnt  the  systems.  We  develop  ccst  corn  pa  liso.us 
wnich  use  presently  available  cost  data.  we  project  tne 
cost  comparisons  into  the  19tJ5  timeframe  by  structuring  two 
scenarious  and  three  cases  within  eacn:  the  "most  likely", 
tne  "optimistic",  and  the  "pessimistic". 

E.  MAJGE  FINDINGS 


1 • Th  a So_t  t wa^e  Aguisit  jog  Cost 

When  we  discuss  the  cost  or  software,  we  distinguish 
between  software  development  costs  and  software  aguisition 
costs.  The  development  is  a "human  intensive"  activity  and 
its  cost  is  high  in  comparison  to  production  costs  cf  LsI 
circuits.  Although  program  development  costs  are  variable, 
the  variability  is  generally  bounded  by  $5  - 5F0  per 

instruction.  The  program  aguisition  cost  is  dependent  on 
the  number  of  potential  users  of  the  pregram.  Software 
development  tools  such  as  editors,  assemblers,  compilers, 
decuggers  and  operating  systems  can  he  bought  for  530  - 
$1000  per  program.  The  aguisition  cost  per  instruction  for 
widely  used  programs  ranges  from  5.001  - $.02,  about  three 
tc  four  ciders  of  magnitude  different  ttcra  the  program 
production  costs.  Therefore  custom  ouilt  software,  which  is 
exclusively  designed  icr  the  Navy  (Crts-2  compilers,  AN/UYK-7 
operating  systems,  AN/UYK-20  operating  systems)  is  high  in 
aguisiticn  ccst  in  comparison  to  widely  used  compilers  and 
operating  systems.  To  minimize  software  costs  it  is 

important  tc  avoid  custom  built  software  as  much  as 

possible  . 

2.  1 he  Hardware  Aguis i t ion  Cost 


It. 


We  again  distinguish  between  hardware  de velopment 
costs  and  natdware  aguisition  costs.  Hardware  desigr  and 
development  is  a "human  intensive"  process,  hence  the  design 
and  development  cost  is  high.  The  hardware  aguisiticn  cost 
varies  widely.  If  a distributee  computer  system  is  built 
from  modular  LSI  single  board  computer  systems  which  are 
widely  used,  the  aguisition  cost  per  computer  is  in  the 
range  from  $500  - $2000.  If  the  computer  is  a custom 
design,  the  price  per  computer,  even  if  LSI  chips  are  used 
in  the  desigr,  jumps  tc  the  range  $20,000  - $50,000.  To 
minimize  aguisition  costs  it  is  important  to  avoid  custom 
designs  and  custom  built  hardware  as  much  as  possible.  In 
the  highly  competitive  LSI  hardware  market,  the  widely  used 
hardware  aguisition  costs  are  likely  to  drop  and  make  the 
future  cost  differential  between  custom  designs  and  widely 
accepted  uesigrs  even  greater. 


ihs  Salihs  ilfiijiisiiaiiaa 


Changes  in  software  have  an  extremely  high  cost  per 
instruction.  Literature  guotes  a range  from  $500  - $8000 
per  instruction.  The  cost  is  dependent  on  hew  modular  tue 
programs  are,  how  well  they  are  documented,  the  complexity 
ct  programs,  the  language  used,  etc. 

Any  errors  in  the  program  which  pass  the  acceptance 
tests  are  particularly  expensive  because  the  raaintainers 
have  tc  become  as  familiar  with  tne  program  as  the 
originators.  Exhaustive  acceptance  tests,  on  the  ether 
hand,  ate  impossible  to  conduct  (There  are  approximately 
1 0 6 4 possiule  program  paths  in  the  Ao-h  pregram).  Modular 
design  and  thorough  module  testing  is  the  way  to  achieve 
s uccess. 
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In-3  cost  differential  oetween  homogeneous  and 
heterogeneous  systems  for  maintenance  and  update  of  software 
depends  on  the  languages  used  to  construct  the  software.  It 
cnly  a single  higher  level  language  is  used,  the  cost 
differential  is  small.  Assumed  here  is  that  the  higher 
level  language  compiler  aguisiticn  cost  has  teen  included  in 
the  sortware  aguisition  cost.  If  assembly  languages  are 
permitted,  the  educational  cost  of  software  maintainers  will 
vary  in  proportion  to  the  number  of  distinct  computer  types 
used  in  the  system. 

4 . I he  Hardware  Maintenance  Cost 

'I he  hardware  maintenance  cost  differential  between 
homogeneous  and  heterogeneous  systems  is  large.  The 
educational  costs  of  maintenance  personnel  are  proportional 
to  the  number  of  distinct  computers  in  the  system.  The  test 
procedures  and  test  programs  necessary  vary  in  direct 
propcrticn  with  the  number  of  distinct  component  computers. 
I he  spare  parts  inventory,  the  paperwork  in  the  supply 
system,  and  the  documentation  at  the  repair  facility  - all 
these  costs  are  multiplied  by  the  number  of  distinct 
computers  in  tne  system. 


d . Cost  Summary  Prolection 

Figure  1.1  presents  the  estimated  cost  comparison 
between  two  i opiera entation  alternatives:  the  homogeneous  and 
the  heterogeneous.  The  homogeneous  alternative  consists  of 
a system  of  identical  LSI  computers  in  a homogeneous 
network.  These  computers  are  commercially  successful  and 
satisfy  military  standard  requirements  imposed  by  the  severe 
environment  in  which  they  must  function.  Three  examples  of 
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presently  existing  systems  are:  Digital  Equipment 
Corporation's  LSI  11,  INTEL'S  8080,  Texas  Instruments'  9900 
family. 


Ihe  heterogeneous  alternative  consists  of  a 
so-called  "mission  computer"  surrounded  by  a variety  of 
possibly  distinct  senscr  embedded  LSI  computers  which  act  as 
pre-processors  to  the  system.  The  system  is  connected  by  a 
time-multiplexed  data  bus,  such  as  the  military  standard 
1b5J.  Present  examples  are  the  F-15,  and  the  F-18  tactical 
systems. 

Ihe  hardware  costs  ate  substantiall y affected  ty  the 
passage  ct  time,  hence  they  are  estimated  ter  1977  and  19t>5 
to  illustrate  that  the  advantage  to  the  homogeneous  system 
becomes  even  greater  as  time  passes.  The  software  costs 
illustrated  are  based  cn  the  navigation,  ballistics,  and 
command  modules  abstracted  in  this  report  from  the  At>-E 
operational  rlight  program.  While  not  a complete  picture  of 
the  VST CL  operational  flight  program,  since  that  program  is 
not  yet  specified,  it  does  provide  a reasonable 
representation  of  the  core  set  of  computations  common  across 
ail  VSTOL  variants. 
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Figure  1-1 


figure  1.1  showy  that  the  estiiated  sottvaie 
aguisiticn  costs  dc  not  differ  substant ially  in  the  two 
alternatives.  There  are  uncertainties  dependent  or  tne 
aguisiticn  strategy.  If  the  Navy  special  language  Ct1£-2  is 
a requirement  ror  all  programs,  including  embedded  processor 
programs,  then  a CMS-T  compiler  would  have  to  be  written  for 
each  computer.  We  assume  that  this  will  not  be  done  and 
that  a variance  wrll  oe  granted  £ol  the  periferal  computers. 
If  a widely  used  higher  level  language  (FORTRAN , BASIC)  is 
permitted,  a relatively  small  aguieition  cost  is  associated 
with  the  compilers  for  the  LSI  computers. 


The  differences  between  the  homogeneous  and 
neterogeneous  alternatives  are  greater  for  the  hardware 
aguisiticn  cost  estimates.  A special  purpose  design  fcr  the 
Navy  cannot  be  cost-shared  and  hence  the  hardware  aguisition 
ccst  for  the  "mission"  computer  is  high  (£50,000).  Tne 
embedded  computers  are  low  cost  items  if  no  uniformity 
requirements  are  imposed  and  eacu  subcontractor  uses  "his 
own"  favorite  embedded  computer.  In  th;  homogeneous 
alternative  embedded  computers  must  oe  identical,  hence  a 
higher  aguisiticn  cost  is  required  if  the  embedded  systems 
must  be  redesigned.  The  estimated  hardware  aguisiticn  costs 
for  the  heterogeneous  system  is  nevertheless  higher. 


Ihe  software  maintenance  cost  estimate  is  higher  for 
the  aetercgeneous  system.  The  cost  ditterence  is  greater  if 
assembly  language  programs  are  used  ir.  the  embedded 
computers. 


Ihe  hardware  maintenance  cost  estimate  has  the 
largest  difference  between  the  homogeneous  and  heterogeneous 
alternatives.  If  the  hardware  reliability  is  as  high  as  is 
expected,  then  the  total  estimated  maintenance  cost  will  be 
lower  than  cur  present  experience  indicates.  The  difference 
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in  total  costs  between  the  design  alternatives  will 
thctetotc  te  less  pronounced  than  shown  in  figure  1.1. 

Not  included  in  this  summary  but  specified  in 
Chapter  IX  is  the  additional  cost  or  aircrart  overdesicn  for 
the  extra  weignt  inherent  in  the  mission  computer  of  the 
heterogeneous  alternative. 


Ihe  total  cost  estimate  comparison  betweer  tue 
system's  alternatives  shows  that  the  homogeneous  system  has 
substantial  advantages  over  the  heterogeneous  alternative. 
However,  to  carry  out  the  homogeneous  design  concept 
requires  a high  degree  of  discipline  and  cooperation  between 
contractors,  subcontractors  and  the  Navy  project  office. 
Because  ^rejects  are  fur.dea  on  the  basis  of  aguisiticn  costs 
rather  than  lifecycle  costs,  the  homogeneous  system  must 
show  its  advantages  during  the  aguisition  phase,  while  test 
cr  the  cost  differential  will  appear  during  the  maintenance 
phase. 


A.  BACKGROUND 

Although  analog  dtvices  which  might  be  called  analog 
computers  have  be«r  used  in  airborne  applications  tor  a long 
time,  digital  computers  have  been  used  only  recently,  in  the 
late  19t>0's  and  early  1970's.  The  Navy  attack  aircraft  Ao-h- 
ana  A7-Z  have  a comprehensive  tactical  system  basec  on  a 
general  purpose  digital  computer.  The  antisut mar ine  warfare 
aircrart,  the  PJ-C  and  SJ-A,  the  radar  surveillance 
aircrart,  ec-C,  and  tne  electronic  warrare  aircratt  Eo-p  ail 
depend  on  a general  purpose  digital  computer  system  as  a 
vital  part  or  tne  weapons  system.  Because  of  decreasing 
costs,  weights,  and  power  requirements  and  increasing 
reliability  and  capability  of  digital  electronics,  the  trend 
toward  more  use  or  digital  technology  is  clear. 

IheLe  is  also  an  observable  trend  in  the  system's 
architecture  of  the  Navy's  presently  acquired  systems.  The 
1-Id  typifies  the  concept  of  the  tactical  system  consisting 
of  a central  "mission  computer,"  a dual  CPU  AN/UYK-14,  which 
is  the  so  called  airborne  Navy  "standard"  computer, 
surrounded  by  a distributed  set  or  "embedded"  computers, 
each  of  which  is  dedicated  to  some  tixed  functional  task 
such  as  navigation,  flight  control,  or  me  control.  The 
"mission"  computers  together  with  the  "embedded"  computers, 
which  may  oe  diftercnt  from  eacn  other,  make  up  a 
"heterogeneous"  digital  system. 


In  lignt  of  tae  rabidly  changing  Large  Scale  Integration 
(LSI)  technology,  there  are  numerous  choices  to  iaplemeut 
future  airborne  systems.  Which  choice  is  made  will  have 
important  consequences  in  cost,  weight,  reliability,  and 
capability.  Ihis  study  addresses  two  major  alternatives  of 
system's  1 nplementaticn:  the  homogeneous  alternative 
consisting  of  a system  of  functionally  identical  processing 
elements  connected  into  a regular  network;  the  hetercgeous 
alternative  which  contains  a central  "mission  computer"  with 
a mix  or  "embedded"  processing  elements  connected  ir.tc  a 
network  ty  a serial  time  multiplex  data  bus,  such  as  tne 
MLSTD  1553(E). 

The  technical  feasibility  of  the  homogeneous  alternative 
is  subject  to  question,  because  there  is  a belief  that  the 
currently  available  LSI  processing  elements  are  too  slew  and 
too  sQall  tc  carry  out  the  tasks  demanded  ty  a real  time 
tactical  system.  A substantial  part  of  this  report  is 
devoted  tc  establishing  the  technical  feasibility  of  the 
homogeneous  alternative. 

Several  reports  have  addressed  the  inplementaticn  of 
tactical  systems  using  LSI  processing  elements.  Tue 
Honeywell  report  [13]  represents  a view  which  anticipates 
that  the  airborne  computing  will  soon  teccme  distributed 
among  identical  LSI  processors  which  are  connected  by  a data 
bus  of  high  data  rate.  The  report  recommends  that  we 
proceed  with  laboratory  models  instead  of  paper  studies. 
Although  the  study  anticipates  microprocessors  of  some 
capability,  the  authors  in  1973  did  not  anticipate  the 
powerful  single  chip  computers  available  in  1977. 

Texas  Instruments,  [4  ] produced  a report  in  1975,  which 
accurately  projected  the  availanility  of  16  bit 
microcomputers  with  multiply  and  divide  functions  executed 
at  the  speeds  which  are  realized  in  1977.  Their  analysis 
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accurately  projects  costs,  develops  design  Bethodolcgy  for 
distributing  computing  aionq  a collection  ot  JO 
independently  operating  processors  connected  ty  a local  buo 
into  affinity  groups.  The  affinity  groups  in  turn  are 
connected  by  a glotal  bus  to  fora  the  tactical  systeir.  Tne 
report  includes  analysis  and  design  tools  which  aie  wcrkeu 
cut  in  great  detail  and  provide  a designer  with  useful  teois 
tc  implement  a tactical  system  with  presently  available 
computers.  Iheir  report  closely  parallels  the  analysis 
rcurd  in  tms  report. 

A report  by  HcDonnell-Douglas  p9]  represents  the  view 
that  a central  mission  computer,  surrounded  by  the  special 
purpose  computers  is  the  preferred  design.  Distributing  tne 
processes  among  many  small  computers  creates  reliability 
problems,  according  to  their  report. 

Sperry  Univac  study  [6]  concerns  itself  mere  with  design 
methodology  rather  than  any  particular  implementation.  Tne 
methodology  suggests  a series  of  seven  steps  which  tends  to 
separate  the  software  design  trom  the  hardware 
implementation.  The  operational  rliuht  program  rs  designed 
m terms  ct  decomposit  ional  units  which  are  at  the  final 
stages  ot  design  mapped  into  hardware  or  firmware. 

A mote  general  report  which  addresses  the  tactical 
computer  needs  not  only  for  airborne  computers  but  tactical 
systems  used  in  the  Army  and  Navy,  was  published  in  1^7i> 
[3]. 


The  Army/Navy  Computer  Family  Architecture  (C  F A) 
Selection  Commit tet • s tinal  report  recommends  the  use  ct  tne 
PDP-11,  ltd  S/J70  or  interdata  based  on  architectural 
suitability,  support  software  availability  and  lite  cycle 
costs.  This  tinal  report  recommended  tc  both  the  Army  ar.d 
the  Navy  a suitable  family  ot  computers  to  iiplement 


I 


tactical  iyitfit.  me  committee  did  net  consider  LSI 
computers,  pcssicly  ueuust  some  or  these  computers  had  net 
teen  announce  at  .he  tra~  the  committee  started  its  work. 
However,  the  committee's  recommendations  are  largely  based 
cn  the  availability  or  support  sottware  ror  these  systems 
whicn  ate  arcaitectuially  acceptable.  Ihe  existing  Navy 
stanaard  computers,  AN/UYK-7  and  AN/UYK-20  railed  to  quality 
architecturally  under  the  criteria  used  by  the  committee, 
and  would  be  poor  choices  because  tne  support  software  base, 
even  at  this  point  in  time,  is  inadequate.  The  comcittee 
did  not  anticipate  the  impact  that  LSI  computers  have  lad  on 
the  cost  cf  support  software.  The  committee  did  not 
dirferentiate  Detween  the  development  cost  of  support 
software  anc  sales  price  cf  support  software  when  the 
customer  base  is  large.  The  committee  tacitly  assumed  that 
sottware  development  would  be  carried  cut  on  the  same 
computers  that  are  used  for  the  application.  There  is 
general  agreement  that  program  development  is  test  dene  on 
special  developmental  systems,  as  is  the  case  with  many  LSI 
computers. 


A hi i HOD  FOR  ESI Id ATI  NO  VSTOl'S  NEEDS 


Jetore  we  can  realistically  compare  alternative  system's 
i uplementaticns,  we  must  estimate  program  size,  execution 
speed  requirements,  and  data  flow  requirements.  We 
introduce  methodology  based  cn  graph  theory,  which  permits  a 
detailed  analysis  cf  execution  speeds  and  data  flows.  we 
apply  tnese  techniques  to  analyse  the  Ao-S  operational 
flight  program. 

if  the  execution  speeds  for  the  ins truct ions  of  a 
particular  computer  are  known,  then  we  can  estimate 
accurately  the  execution  times  that  a program  segment  would 


require  it  executed  on  that  computer.  Similarly,  it  we  know 
the  data  bus  data  transfer  speeds,  we  can  accurately 
estimate  tne  time  required  tc  transfer  data  between 
computers.  Based  on  this  analysis,  we  can  accurately 
estimate  the  number  or  processors  needed  to  carry  out  the 
At>-E  operational  fliqht  program  using  a homogeneous 
distributed  system  or  a heterogeneous  distributed  system. 

because  system's  needs  for  VSTOL  are  similar  to  fixed 
wing  aircraft  which  carry  out  the  same  functions,  we  can  use 
the  Ab-fc  tactical  program  as  a starting  point  for 
extrapolating  the  operational  program  requirements  for 
VSTOL,  attack  version.  Similarly,  the  S3-A  can  be  used  as  a 
starting  point  for  estimating  the  system's  requirements  for 
VSTOL  used  as  an  antisubmarine  aircraft. 

By  establishing  feasibility  of  homogeneous  distributed 
systems  with  presently  available  commercial  LSI  processors, 
it  is  clear  that  the  improved  capability  of  the  LSI 
computers  by  19B0's  will  reduce  the  number  of  processors 
required  and  also  reduce  the  presently  experienced  hardware 
costs . 

i 

C.  OciG  A N IZ  A I ION  OF  THE  REPOFT 

Chapter  III  describes  the  so-called  LSI  revolution,  its 
implication  both  in  hardware  and  software  development.  The 
industry  trends  in  process  control  applications  and  emteddeJ 
computing  are  discussed  and  related  to  the  future  of  Navy 
airborne  tactical  computing . 

Chapter  IV  states  the  problems  posed  by  rapidly  chanqing 
technology.  Design  principles  applicable  to  aitfccrne 

t ictical  system's  software  and  hardware  design  are  stated.  I 
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homogeneous 


and 


Ihe  two  major  design  alternatives: 
heterogeneous  are  discussed  in  detail. 


Ihe  methodology  for  the  analysis  or  distributed  systems 
is  given  in  Chapter  V.  Execution  time  analysis  techniques 
and  data  flow  analysis  are  both  based  on  the  concept  of 
graphs.  From  this  analysis  execution  times  can  be 
estimated,  data  flow  requirements  between  processing 
elements  can  be  determined  and  partitioning  strategy  can  be 
formulated. 


Chapter  VI  applies  the  analysis  methodology  to  the  A6-E 
system.  A detailed  association  of  computational  steps  with 
program  segments  is  obtained  from  tne  A6-E  operational 
flight  program  documents.  Data  flow  requirements  between 
suggested  pregram  partition  elements  is  calculated  and 
program  size  estimates  are  given  in  both  higher  level 
languages  and  a machine  language.  Estimates  of  the  VSTCL 
operational  flight  program  are  obtained. 

Ihe  systems  implementation  alternatives  are  considered 
in  Chapter  VII.  A proposed  homogeneous  distributed  system's 
design  using  presently  available  LSI  processors  is  compared 
with  a heterogeneous  design.  Ihe  implementations  with 
improved  technology  in  the  future  will  allcw  more  capable 
systems  with  smaller  computers,  less  weight  and  at  less 
cost. 


Comparisons  in  the  reliability  of  the  designs  are 
considered  in  Chapter  VIII.  Economic  analysis  with  two 
scenarios  for  future  possibilities  are  considered  in  Chapter 
IX. 
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- IWiLICAliONS  OF  LARGE  SCALE  INIEGRATION 


A.  TECHNOLOGICAL  CHANGE  AND  LSI  IMPLICATIONS 


The  technology  of  Large  Scale  Integration  is  one  of  the 
most  significant  technological  events  in  the  twentieth 
century.  A machine  can  now  le  endowed  with  "intelligence". 
Although  computers  have  been  in  existence  for  more  than 
thirty  years,  only  very  special  machines  could  afford 
"intelligence".  For  example,  the  Mars  lander  was  one  such 
machine.  In  the  near  future  many  machines  will  have 
capabilities  of  the  Mars  lander. 

Ihe  agriculture  industry's  tractor  which  converts 
cnemical  energy  into  mechanical  work  has  made  it  possible 
for  two  percent  of  the  population  in  the  United  States  to 
feed  net  only  the  entire  population  of  United  States  but 
millions  of  ethers.  At  the  turn  of  the  century  sixty 
percent  cf  the  population  was  required  tc  feed  the  rest. 
Similarly,  with  "smart"  machines,  the  productivity  cf  each 
cf  us  can  increase  to  such  an  extent  that  cnly  a minority  of 
workers  are  required  in  the  direct  production  of  the  world's 
goods,  the  rest  could  be  employed  in  services  or  information 
processing.  Radical  changes  will  tare  place  in  fcett  tne 
social  structure  and  our  values  as  a consequence  of  a 
silicon  chip  which  can  be  made  into  a willing  slave,  a 
skilled  pilot,  or  a deadly  weapon. 

Ihe  technology  of  Large  Scale  Integration  affects 
military  aircorne  systems  in  three  major  ways: 
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1)  Ihe  cost  of  the  hardware  is  potentially  radically 
reduced. 


2)  The  systems  weight  and  power  reguireraents  are 
radically  reduced. 

J)  The  system's  design  distributes  the  computing  among 
several  computers.  Distributed  system's  architecture  allows 
ruture  add-ons  to  be  made  in  an  orderly  way. 

In  order  to  gain  insight  into  why  the  radical  cost 
reductions  ir.  hardware  are  possible,  we  start  with  cost 
analysis  tor  LSI  technology. 

In  producing  any  product,  the  cost  can  be  divided  into  a 
nonrecurring  cost,  NRC,  and  a recurring  cost  per  unit  item, 
RCU . Ir  we  produce  N items  of  a certain  type,  then  the 
sales  ^ rice  per  unit,  SU,  should  be  such  that  the  income  on 
the  left  cf  the  ineguality  exceeds 

N * SI  > N*RCU  ♦ NRC 


production  cost  on  the  right.  In  general,  the  guantities  in 
this  formula  are  time  dependent,  sc  that  each  should  be 
expressed  more  accurately  as  N ( t)  , SU  (t)  , RCU  (t)  , NRC  (t ) . 
In  order  fcr  the  producer  to  continue  successful  operation 
in  the  lcng  run,  at  seme  point  in  time 


T T T- 

^N (t) *SU  (t) dt  > U (t)  *RCU <t) dt  ♦ \NRC (t) dt 


o 


It  depends  on  the  company's  pricing  policy  whether  or  not 
the  inequality  holds  at  several  points  in  time  or  strictly 
in  the  long  run.  Fcr  companies  which  do  net  change  their 
sales  price,  the  above  formula  simplifies  tc 
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6U  > RCU  ♦ M RC/N  (t) 


1 

M 


lo  flame  the  cosi  issues  in  LSI  technology  by  this 
inequality,  first  note  that  the  microelectronics  issue  of 
the  Scientific  American  [21]  breaks  down  the  manuf act  tier • s 
recurring  cost  of  producing  the  LSI  chip  as  fellows. 


test  Component 

Cost/Chip 

Cum  Ccst/Chip 

Untested  chip 

cn  a water 

iO.  10 

$0.  10 

Iestcd  chip 

assuming  20%  yiela 

$1.00 

$1.  10 

Packaging  and  package 

testing  a chip 

$0.50 

$1.60 

Assembling  chips 

cn  a circuit  board 

100  circuits/board 

$ 1. 00 

$ i . oO 

Caoinet  and  power 

$0.35 

$*.95 

supply  icr  a 20 
tcard  system 


Ihe  nonrecurring  costs  are  measured  into  the  millions  of 
dollars.  These  costs  include:  the  cost  of  market  surveys  to 
decide  what  to  make,  the  logical  design,  the  layout  desiqn, 
the  documentation  tor  the  design,  design  of  tests  for  each 

chip,  the  writing  of  users  manuals,  advertizing  and  | 
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disseminating  information  about  the  product,  life  testing, 
user  education  etc.  An  estimate  for  the  nonrecurring  costs 
associated  with  the  very  successful  INIEI  8080  chip  is 
45 ,000,000. 

The  8080  chip  sells  from  several  distributors  at  $15  per 
cnip  in  single  quantities.  Putting  the  numbers  into  the  cost 
formula 


415  > 41.6  +45  * 10VN  (t) 


shows  that  sales  of  the  number  of  8080  chips  to  date  has 
totalled  at  least  about  half  million.  Later  in  this  report 
a sales  estimate  of  abcut  6 * 106  microprocessor  devices  for 
the  industry  is  made.  With  INTEL  holding  abcut  30*  of  the 
market,  that  would  be  roughly  1.6  * Id6  devices  or  a total 
ccst  per  chip  of  45. 

It  is  very  important  to  understand  that  Large  Scale 
Integration  by  itself  will  net  reduce  the  ccst  of  coiputer 
hardware.  It  is  only  when  a chip  or  a system  becomes 
popular  that  the  sales  price  drops  to  recurring  production 
ccsts.  As  an  example,  the  AN/UYK-14  is  built  frem  LSI 
chips.  The  total  estimated  production  cost  for  the  chips 
is : 


Memory  65K  x 16 
CPU 

I/O  channels 

Miscellaneous 

Total 


= 65  chips,  16K  bits  each 
= 14  chips 
= 32  chips 
= 20  chips 
=131  chips 
x 43.00 


Estimated  recurring 


J 


I 


- 


32 


production  cost  = $393 


khile  it  is  true  that  military  specifications  require 
different  packaging  and  additional  testing  of  the  chips, 
which  causes  a cost  escalation  by  a factor  cf  2 - 3 per 
chip,  the  estimated  recurring  production  costs  would  still 
range  from  $600  - $1200  per  system. 

The  present  aguisition  cost  of  the  AN/UYK-14  is 
approximately  $50,000.  There  is  no  reason  to  suspect 
excessive  profits  simply  because  the  nonrecurring  design, 
test,  documentation  and  customer  education  costs  are  high 
and  the  potential  sales  volume  is  relatively  low.  Hence 
even  with  a contract  strategy  which  separates  develcpment 
from  production  phases,  as  with  the  AN/UYK-14,  the 
contractor  is  still  prcnably  amortizing  development  costs  in 
the  production  phase  of  the  contract. 

In  order  to  make  effective  use  of  the  LSI  technology,  it 
is  important  to  select  a system  which  is  widely  used.  Ihe 
ncnrecurring  production  costs  can  then  be  shared  among  a 
large  population  of  users. 

A massive  use  of  a system  has  also  important 
implications  in  software  costs.  The  same  ccst  formula  can 
be  applied  tc  software  production. 

SU  > RCU  ♦ NRC/N  (t) 

The  ncnrecurring  cost  is  estimated  to  be  in  the  range  *5 
- $60  per  instruction.  The  recurring  cost  usually  involves 


33 


II 

duplicating  a magnetic  tape,  a paper  tape,  a floppy  disk,  or 
a deck  cf  cards.  In  all  cases  the  recurring  cost  is  almost 
negligible.  Therefore,  the  aquisition  cost  of  a program 
which  has  a large  number  of  users  becomes  small.  For 
example,  a floppy  disk  operating  system,  including  utility 
programs  such  as  assemblers,  editors,  debuggers,  compilers, 
ter  an  INIEL  dOdO  system  sells  for  *75  per  cepy.  The  length 
cf  the  program  is  about  30,000  instructions.  Therefore  the 
aguisiticn  ccst  per  instruction  is  $.0025.  Typical  sales 
prices  ter  FORTRAN,  BASIC,  COBOL  compilers  range  between 
$500  - $1000  per  compiler.  This  contrasts  with  the  Navy's 
estimated  aquisition  cost  [ J ] ot  $4,900,000  for  the  CMS-2 
language  compiler.  Even  if  there  are  100  Navy  program 
development  centers  using  this  compiler,  tne  cost  to  the 
user  is  $49,000. 


c.  INDUS! SI  TRENDS  IN  EMBEDDED  COMPUTING 

Microprocessors  are  architecturally  designed  to  permit 
maximal  use  cf  the  chip  area.  The  continuing  trend  is  to 
place  mere  and  more  circuits  on  a chip.  The  trend  is  iu 
three  directions: 

1)  The  n icrocomputor  on  the  chip  (INTEL  8048,  TI-S940). 

2)  Greater  arithmetic  capability  on  the  CPU  chip 
(TI-9900)  i.e.  1o  bit  multiply  and  divide  function  cn  one 
chip. 

J)  Byte  slice  chips  which  can  oe  used  tc  build  computers 
cf  arbitrary  word  length  (INTEL  3000,  AMD  2900) . 


A few  years  ago  the  mcrocomputer  system  contained  a 
board  which  had  the  CPU  with  additional  chips  to  coramur icate 
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with  memory  and  input  /output.  The  memory  and  input/cutput 
ports  were  on  separate  boards.  The  single  beard  computers 
combine  the  CPU,  memory,  and  input/output  circuits  cn  one 
toard.  The  latest  trend  is  to  put  the  CEO,  memory  and 
input/output  circuits  cn  a single  chip. 

Undoubtedly  the  most  useful  chip  will  be  the  one  which 
is  arithmetically  powerful,  contains  a sufficient  amount  of 
memory  which  can  be  extended  and  has  input/cutput 
capability. 


C.  THE  fUIUEE  OF  NAVY  AVIONICS 


If  the  single  chip  computer  of  the  1980's  will  have 
8K-I0K  bytes  of  memory,  it  will  be  powerful  enough  to 
perform  each  cf  the  modular  functions  which  are  currently 
iaplemented  in  airborne  tactical  systems. 

The  leading  micr cccmputer  manufacturers  have  developed 
parallel  tiae  multiplexed  bus  technology  (INTEL-KUllIEUS, 
DEC  UNIbUS,  II  TI LINE) . The  hardware  bus  technology  is 
supported  ny  distriDuted  single  board  real  time  executive 
software  so  that  the  user  need  not  involve  himself  with 
anything  tut  applications  programming. 

3y  the  first  half  or  the  1980's  powerful  distributed 
systems  consisting  cf  a network  of  single-chip  computers  on 
cne  board  will  be  replacing  the  present  single  beard 
computers. 

Auxiliary  memory  in  the  form  of  magnetic  bubbles  and 
charge  ccupled  devices  will  provide  essentially  unlimited 
auxiliary  memory  for  these  applications  where  auxiliary 
memory  provides  memory  space  for  occasionally  used  procrams. 
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Ihe  presently  limited  human  capability  of  writing  pregrams 
will  be  the  only  delay  in  the  process  cf  creating  useful 
systems. 

Ihe  Navy  has  an  opportunity  to  use  this  new  technology 
to  its  fullest,  it  cannot  afford  to  do  so  ty  continuing  to 
create  its  own  special  brand  cf  computers  (AN/UYK-lh)  and 
continue  to  use  its  own  special  brand  of  languages  (CKS-2) . 
The  dedicated  airborne  tactical  systems  can  te  designed  and 
iaplemented  by  the  use  of  distributed  isi  processors. 
Cnapter  IV  and  Cnapter  VII  shew  in  detail  how  this  can  be 
accomplished  tor  the  Ao-ii  system,  or  systems  similar  in 
function,  VSTOL  . Cur  design  makes  use  cf  the  presently 
available  LSI  processors  in  crdc-r  to  establish  feasibility. 
Ihe  more  powerful  LSI  processors  likely  tc  exist  by  1965 
will  mane  future  system's  design  easier,  the  total  systems 
weight  s usbstantially  smaller  and  the  computer  system's 
reliability  higher. 


IV 


A.  LtSIoN  PRINCIPLES 


«•  ii)  t Ju^iion 

'Ihis  section  uiscusses  some  principles  lor  tne 
design  ct  large,  special  purpose  computer  systems  such  us 
occur  on  aeroplanes,  ships,  and  ether  large,  complex  systems 
involving  information  gathering,  transformation,  and 
transmission. 

First,  the  words  "large'*  and  "system"  imply  a 
systems  design  approach,  which  in  turn  means  that  we  ask, 
"What  must  we  uo?"  rather  than  the  usual,  "what  can  we  do*"' 
Cf  course  in  tne  end  we  must  te  able  to  carry  cut  tne 
design,  tut  understanding  the  systems  eenstraints  should 
precede  putting  something  together  to  see  if  it  "works". 

Second,  we  have  learned  from  past  experience  that 

lj=  d major  problem  in  computing  systems.  Why  is 
testing  sc  hard?  At  the  bottom  is  tne  simple  fact  that  the 
growth  ot  the  number  or  combinations  o:  the  various  parts  or 
a typical  computer  system  (both  hardware  and  software)  is 
astronomical;  it  is  totally  impractical  to  try  every 
combination  tc  see  it  it  works.  For  example,  a million 
computers  working  for  a million  years  at  a million  times 
current  speed  (a  million  operations  per  second)  can  dc  less 


ot  the  possible  cw  tit  by  on  bit  / 


than  one  millionth 


multiplications.  Thus  we  cannot  nope  to  tost  the  entire 
complex  system  as  a whcle,  we  can  only  verity  that  ter  an 
infinitesimal  traction  or  special  situations  the  system 
works,  and  then  hope  that  the*  rest  is  correct.  rhtrefore, 
we  must  actively  seek  designs  that  make  it  possible  tc  test 
the  parts  separately,  and  then  test  the  interconnections  at 
the  interlaces  one  by  or.e  at  most. 

As  a practical  example  ot  this  combir.ator ial  growth 
principle,  consider  the  tact  that  it  is  easier  to  design  an 
integrated  circuit  than  it  is  to  design  the  tests  for  it; 
that  it  is  easier  to  manufacture  an  integrated  circuit  than 
it  is  tc  test  it  afterwards  to  see  it  it  operates  properly; 
that  it  is  easier  to  build  software  and  other  programs  than 
it  is  to  test  them. 

As  an  example  ot  two  different  approaches  to  the 
design  ot  a settware  package  consider  the  problem  of  writing 
a program  to  integrate  a particular  second  order  non-linear 
ordinary  differential  equation.  Ii  you  Degin  by  writing  a 
general  purpose  integration  routine,  then  you  can  test  it 
using  various  standard  functions  like  sines  and  cosines, 
growing  and  decaying  exponentials,  Bessel  functions,  etc. 
ii  it  h a wide  variety  of  well  known  functions  you  can  probably 
cover  most  ot  the  particular  aspects  ot  the  equation  you 
have  to  solve.  Finally  by  specializing  the  general  purpose 
routine  to  the  particular  problem  , you  will  have  a great 
deal  more  confidence,  at  a lot  less  labor,  than  witt  the 
direct  approach  to  the  special  case.  Ot  course  the  general 
program  may  well  oe  slower  and  use  moLe  storage  that  tne 
optimal,  special  p'urpose  routine,  but  by  going  the  general 
purpose  path  you  have  gained  a lot  in  both  reliability  and 
savings  in  the  effort  in  testing. 

Ihe  same  applies  to  hardware.  It  has  been  observed 
in  the  literature  that  it  is  easier  to  test  a computer  with 
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a "random  access  storage"  device  than  it  is  one  with  a "read 
cniy  storage"  device.  In  the  latter  case  ycu  must  provide 
extensive  testing  eguipment  outside  tae  computer  to  dc  tne 
testing;  in  the  general  purpose  case  you  car.  use  the  cevice 
itselt  to  aid  in  much  cf  the  testing. 

From  these  examples  we  extract  three  principles: 

1.  we  must  deliberately  seek  designs  that  make  the 
testing,  fccth  of  hardware  and  software,  as  easy  as  possible; 
not  only  initially  but  over  the  life  of  the  system  with  its 
many  changes  and  upgrades. 

2.  General  purpose  hardware  and  software  offers 
flexibility  at  tne  testing  stages,  and  furthermore  it  tends 
to  be  composed  of  relatively  independent  parts.  Therefore 
at  every  stage  the  general  purpose  system  should  be 
considered  instead  of  special  purpose  tncxs  that  appear  to 
save  money  and  effort  at  the  moment. 

i.  A homogeneous  system,  both  hardware  and 
software,  tends  tc  be  easier  to  test,  both  in  th*3  designing 
cf  tne  tests  and  their  execution.  Furthermore,  there  is  a 
great  degree  of  self-testing  of  the  homogeuecus  structure  as 
it  is  used  in  the  various  ways  in  the  whole  system.  Any 
errors  that  are  found  and  removed  are  thereby  removed  from 
all  their  appearances  at  the  same  time  - they  need  net  be 
tcund  again  and  again  if  the  correcting  is  done  to  the 
system,  net  to  the  detail  where  it  is  first  found. 

tut  it  is  obvious  that  the  prculem  to  be  solved  by 
the  whole  computer  system  is  highly  varied.  Therefore  the 
underlying  problem  is  to  confine  tnis  variability  as  much  as 
possible,  and  to  construct  as  regular  a system  as  possible 
sc  tnat  tne  regular  system  may  be  tested  relatively 
independently  of  the  particular  details  ot  the  system  we 
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It  it  is  still  doubted  that  testing  is  the  problem, 
tnen  consider  the  endless  number  or  field  changes  that  hill 
cccur  during  the  life  cf  the  system.  The  cost  of  these 
changes,  and  the  risks  of  errors,  will  greatly  exceed  the 
cost  of  the  initial  construction  ir  tne  classical  methods  of 
computer  system  design  are  used.  In  cur  judgemert  tne 
solution  to  the  problem  of  designing  a computer  system  lies 
along  tne  lines  indicated  - regular,  systematic,  general 
purpose  systems  so  that  the  testing  problem  car  be 
adequately  handled.  Once  the  general  system  is  tested,  then 
the  special  cases  cr  the  particular  problem  can  be  usee  with 
fair  confidence.  The  cost  is  that  somewhat  mere  capacity  in 
speed  ana  storage  is  needed  (or  equivalently  a few  more 
computer  chips  are  needed)  . Estimates  suggest  that  this 
extra  cost  is  in  the  few  percents,  possibly  in  the  tens  of 
percents,  but  is  nowhere  near  double  the  minimal  capacity. 

2.  Generalized  Testing 

It  ccmes  as  a surprise  tc  many  people  that  there  can 
be  general  purpose  testing  methods  that  are  relatively 
independent  cf  what  is  being  tested.  A simple  example  of 
this  is  the  testing  of  the  computed  answers  cf  a sequence  of 
equally  spaced  function  evaluations.  Typically  this  spacing 
will  be  close  enough  fer  the  function  to  be  "smooth".  Thus 
the  usual  method  of  constructing  a dirfetence  table  cf  the 
function  can  be  used  tc  reveal  isolated  errors.  Similarly, 
in  flight,  streams  cf  smooth  data  can  be  checked  for 
smootnness,  and  isolated  errors  located  as  they  occur. 

Another  example  cf  generalized  testing  is  as 
fellows.  Given  a double  precision  routine  f cr  integrating 
ordinary  differential  equations  (in  practice  this  should 
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include  tue  ability  to  handle  given  singularities)  one  can 
test  library  programs  of  special  functions  by  supplying 
their  dirterential  equations  and  starting  values,  and  then 
comparing  the  results  at  a tight  net  of  points.  One  gets 
tens  ot  thousands  cf  checks  without  any  human  ever  being 
tethered  with  providing  the  check  data.  The  same  tool  works 
cn  most  special  functions,  and  once  tested  cr  a couple  of 
functions  it  is  probably  well  debugged.  The  general  purpose 
tester,  uy  its  generality,  gets  debugged  early,  so  that 
apparent  errors  that  later  appear  are  most  likely  due  to  tne 
program  tested  not  the  test  program  (which  in  the  past  has 
be»=n  one  cf  the  curses  of  testing).  The  errors  in  the  tester 
are  much  more  likely  to  be  discovered  from  its  multiple  use 
than  are  these  of  special  purpose  testers. 

As  a final  example  of  general  purpose  testing,  cue 
can  test  a data  transmission  system  by  encoding  a random 
input  message  into  an  error  detecting  and/or  ar.  error 
correcting  system,  and  at  the  receiving  end  isolated  errors 
can  be  detected  witnout  knowing  what  that  input  was.  Of 
course  if  the  same  random  number  generator  w«re  at  the 
receiving  end,  a more  complete  check  could  be  obtained. 

Inis,  then,  is  one  of  the  things  we  seek;  general 
purpose  methods  of  testing  that  can  be  autemated  ir  the 
sense  that  humans  dc  not  have  to  construct  the  correct 
answers  to  be  used  in  the  testing.  Human  capacity  is  too 
limited  to  do  much  this  way.  Such  a general  purpose  tester 
can  supplement  the  comparatively  few  tests  that  humans  can 
devise  and  apply  tc  the  whole  system.  We  need  an  ensemble  ol 
tests  that  do  not  require  human  thinking  to  apply  to  each 
one  , sc  that  from  the  outputs  alone  the  machine  itself  can 
locate  many  (not  all)  errors.  Thus  the  computing  capacity  of 
the  system  can  be  used  to  test  itself  without  exhausting  the 
human  invention  of  special  tests  and  the  efforts  necessary 
tc  apply  them. 
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J.  listing  Hardware 

In  practice  the  manufacturer  teats  his  product  as 
much  as  he  can,  but  it  is  in  the  field  use  ever  a wide  range 
cf  users  that  the  final  bugs  of  a complex  piece  of  hardware 
are  found.  Ihe  same  is  true  of  the  computer  chip 
manufacturer;  in  the  long  run  they  must  depend  cn  the 
testing  power  of  daily  use  tc  locate  the  residual  errors. 


'Ihis  suggests  that  when  possible,  standard,  widely 
used  computer  chips  be  used  rather  tnan  special  purpose 
cnes.  In  the  long  run  more  will  be  accomplished  in  most 
cases.  Ihis  is  not  to  say  that  special  testing  of  chips 
should  net  be  done  locally,  but  that  these  tests  should  be 
directed  towards  the  special  circumstances  of  their  use. 
Again,  it  is  completely  hopeless  to  test  every  combination 
cf  so  couple*  a device  as  a microcomputer . 


If  the  same  kinds  of  general  purpose  chips  are  used 
throughout  the  system,  then  the  testing  is  much  reduced; 
alternatively,  given  the  same  amount  of  testing  resources,  a 
few  types  of  chips  can  be  more  completely  tested  than  can  a 
wide  variety  of  chips. 


Along  these  lines,  apparently  very  little  is  now 
known  about  the  kinds  of  failures  that  modern  integrated 
chips  have.  And  until  they  are  better  known,  it  is 
impossible  tc  come  up  with  good  design  to  compensate  for  the 
failures.  Once  the  "ncise"  of  the  failures  is  known,  then 
there  are  many  different  ways  ct  compensating  for  their.  It 
compensation  for  errors  is  made  both  for  these  that  do  occur 
and  for  those  that  are  merely  thought  to  occur,  then  much  of 
the  effort  will  ba  misdirected.  Thus  it  is  believed  that 
the  useLs  should  begin  serious  life  testing  ot  commercial 
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chips  sc  that  when  the  time  occurs  for  the  final  desicn  to 
te  made  from  the  integrated  circuits,  the  basis  tor  good 
design  will  be  Known.  Ir  the  testing  is  started  shortly 
cerore  the  final  design  must  be  made,  then  the  life  testing 
will  have  tcc  short  a time  to  be  meaningful. 

4 . fie 1 o^e  Computing  from  Unreliaul t farts 


Ihis  is  not  a new  field.  Error  detecting  and  error 
correcting  cedes  have  been  knewn  and  used  for  many  years. 
Ine  codes  in  the  literature  have  been  designed  mainly  for 
“white  noise".  Special  situations  and  particular  failure 
modes  require  other  inventions,  tut  the  field  is 
sufficiently  well  known  so  that  invention  is  not  hard  to  do. 
for  example,  suppose  you  decide  to  use  read  only  storage 
devices  fer  all  programs,  but  that  occasionally  such  storage 
devices  fail  completely.  How  does  one  construct  a 
reasonacie  way  for  recovering  without  duplicating  all  or 
storage?  One  way  is  tc  put  an  error  correcting  code  or  each 
storage  chip,  and  this  will  allow  isolated  errors  tc  oe 
corrected.  These  error  correcting  codes  can  have  their  tits 
in  location  000...  and  the  top  end  of  the  chip  without  much 
trouble,  so  that  the  checking  bits  are  not  scattered  all 
ever  the  storage  device.  If  a larger  failure  occurs,  say  a 
whole  bank  goes  out,  or  the  error  rate  rises  sharply 
indicating  a disaster  in  the  near  offering,  then  we  can  do 
the  following.  We  carry  a spare  storage  device  which  has 
the  logical  sum  of  all  the  ether  storage  units,  except  the 
failing  cne,  into  the  selected  spare,  we  can  reconstruct  the 
falling  cna  (without  reading  it  at  all)  . Any  isolated  errors 
in  it  can  be  corrected  by  its  own  error  correcting  code.  It 
is  not  teinq  claimed,  in  the  absence  of  any  reliable  data, 
tnat  this  should  be  done  - it  is  given  only  as  an  example  of 
hew  one  car  compensate  for  unreliable  parts  without  the 
heavy  cost  ot  duplicating  every  part,  or  even  triple  or 
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"quadding"  each  part.  The  more  parts  you  put  into  the  total 
system  the  acre  failure  you  will  have  and  the  less  you  will 
be  able  to  test  the  individual  parts  (since  it  is  supposed 
that  you  have  a fixed,  finite  amount  of  effort  to  do  this) . 
More  intensive  checking  on  fewer  parts  is  tetter  that  less 
intensive  checking  on  more  parts. 


5.  listing  Software 

Just  as  using  the  same  kinds  cf  parts  in  the 
hardware  greatly  eases  the  problem  of  testing,  so  toe  will 
the  use  of  the  same  kinds  of  software.  Care  snould  be  taken 
tnat  the  same  functions  are  not  programmed  in  trivially 
different  ways  in  different  parts  of  the  network  of 
computers.  The  software  should  be  approached  as  a whole  - 
systems  design  is  necessary  in  software. 

Since  the  software  must  do  different  things,  it 
fcllcws  that  there  must  be  differences.  How,  then  can  we 
get  homogeneity  in  it?  One  method  is  tc  start  with  the 
mathematical  equations  in  a standard  notation  (say  FORTRAN) 
along  with  the  corresponding  Eoolean  logical  realionships 
and  the  timing  conditions.  Then  using  appropriate  general 
purpose  compilers  (say  FORTRAN  plus  a separate  timing 
checker)  we  can  get  the  code  we  need  generated  by  the 
machine  itself. 

If  an  error  occurs,  there  will  be  a great  tendency 
for  the  programmers  (judging  by  past  experience)  to  "patch 
in  machine  code".  This  should  be  resisted  as  much  as 
possible.  Instead,  go  back  and  fix  the  cause,  the  original 
statements,  the  bug  in  the  compiler,  or  whatever  it  turns 
out  to  te,  tut  do  not  fix  the  isolated  errer  as  an  isolated 
error.  The  object  should  be  to  get  all  the  final  code  tc  be 
machine  generated  in  a uniform  fashion  by  as  simply 
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constructed  compilers  a possible.  Ihus  by  testing  tne 
general  purpose  compilers  on  many  problems  where  the  answers 
are  easily  known  and  checked,  the  compilers  car  bt- 
thoroughly  tested.  Then  (us  in  the  earlier  cited 
di tterential  equation  example)  the  special  cases  that  arise 
in  practice  will  be  more  surely  compiled  correctly, 
furthermore,  all  the  inevitable  changes  that  arise  in  ta« 
course  or  the  life  or  tne  aeroplane  will  use  the  same  well 
tested  compilers,  rather  than  going  through  the  hands  cf  new 
programmers  who  will  have  forgotten,  if  they  ever  knew,  why 
things  were  as  they  were. 

hhile  we  believe  that  much  more  can  be  dene  to 
create  hcaogeneous  software,  the  appropriate  theory  is  not 
yet  available,  so  the  above  is  the  best  we  can  recommend  at 
tnis  time. 

An  example  or  getting  fairly  homogeneous  software  is 
the  idea  cf  having  a table  of  status  values  and  a program 
that  uses  the  table  to  decide  what  to  do  next.  Thus  all  the 
priorities  are  easily  located  and  isolated  for  close 
inspection  and  control.  The  table  values  can  be  easily 
changed  in  mid  flight,  but  the  formula  or  evaluation  should 
be  changed  only  after  long,  careful  stuay  cn  the  ground. 


o . ks So£twa£e  f£om  Unreliable  il 


The  same  problems  of  reliability  occur  in  sottware 
as  occur  in  hardware,  though  perhaps  a bit  more  severely. 
Ihe  answer  we  hav«  given  above,  use  the  system  to  generate 
tne  software  rather  than  let  unreliable  humans  touch  the 
final  version,  seems  to  be  the  best  protection  against  the 
all  too  common  isolated,  foolish  errors. 

More  neeus  to  be  done  along  these  lines,  but  studies 
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of  the  kinds  or  software  errors  that  occur  are  too  few  and 
tco  scattered  to  be  very  useful  at  this  time.  3y  the  time 
software  is  to  be  built,  much  more  will  have  been  discovered 
cn  how  errors  arise.  But  the  principle  that  the  machine 
should  write  the  final  code  will  still  apply. 

Eault  tolerant  computing,  both  software  and  hardare, 
has  received  extensive  attention  in  the  literature  and 
should  ret  be  ignored.  Eut  so  far  as  we  can  see  from 
moderately  careful  study,  there  are  nc  fundamental 
principles  in  all  that  has  been  written.  Instead,  there  are 
many  good  remarks,  observations,  and  suggestions  that  should 
not  be  ignored,  but  neither  should  it  be  depended  upen  too 
much. 

7.  Resting  the  Statement  cf  the  Problem 

Even  if  the  hardware  runs  correctly  and  the  software 
is  written  tc  specifications,  there  is  still  the  chance  that 
the  given  equations.  Boolean  statements,  and  timing 
conditions  are  wrong.  Thus  there  must  te  testing  of  them 
tco,  as  well  as  the  whole  system.  First,  many  of  the 
equations  that  are  to  te  used  cannot  be  completely  new;  much 
cf  the  material  mast  have  been  used  in  similar  situations, 
and  these  should  be  used  whenever  possible  to  compare  with 
what  is  being  proposed. 

Second,  it  is  possible  tc  design  systems  simulators, 
much  as  has  teen  already  done  fer  some  parts  cf  the  problem, 
that  will  test  the  system  behavior  as  a whole  before  it  is 
constructed  in  hardware  and  software,  and  can  also  te  used 
to  generate  check  tests  on  the  complete  target  system. 
Several  systems  simulators  of  varying  degrees  of  detail 
should  te  seriously  considered. 


laird,  it  is  possible  to  build  test  equipment  to 
simulate  reality  so  that  the  assembled  system  has  pseudo 
real  signals  as  inputs.  For  example,  a simulated  target  can 
be  roiled  across  a hangar  floor  to  see  that  the  numbers  at 
various  places  in  the  computet  system  ate  vety  close  tc  the 
theoretical  ones.  Much  as  it  seems  tc  be  trivial,  the 
testing  cl  the  original  proposed  system  is  necessary.  As 
experience  has  shown,  errors  can  creep  in  at  this  early 
stage,  let  alone  at  later  stages  when  small  (apparently) 
changes  in  the  terminal  sensors  and  effectors  are  made, 
bach  such  change  requires  a careful  examination  to  see  if 
the  changes  are  consistent  with  ether  assumptions. 


6.  ^umaac^ 


liistcry  has  shown  that  the  past  habit  of  "letting 
testing  occur  in  its  natural  place"  is  very  expensive  . The 
combinatorial  complexity  of  computers,  beta  hardware  and 
sortware,  makes  complete  testing  or  current  systems 
impossible. 

A rew  people  have  finally  realized  that  design 
Begins  with  testing  (acceptance  tests  if  you  wish) . Tc  not 
design  what  ycu  will  net  be  able  to  test  carefully. 

Generally,  small,  standard,  flexible  units  are  more 
easily  tested  then  are  specially  designed  cnes.  Thrcugn 
use,  isolated  errors  that  escape  the  initial  tests  are 
caught.  Cnee  caught  the  error  is  to  be  removed,  net  by 
patching,  but  by  careful  analysis  cf  hew  it  escaped  the 
testing,  and  then  the  cause  is  removed. 

General  purpose  testing  (both  initially  ar.d  in 
flight)  is  an  area  that  otters  great  returns  from  limited 
human  eftert,  and  should  be  pursued  further. 


*4  7 
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TW 0 ALTERNATIVES:  HOMOGENEOUS  Otf  HETEROGENEOUS 


1 • iiS  t£il'Ut  cd  De dica t ed  Computing 


Ihe  term  distributed  computing  is  a troad  terra  which 
has  a widely  different  meaning  to  different  people.  An 
attempt  to  define  the  term  "sharply"  leads  to  disagreement 
and  sometimes  even  emotional  outbursts  simply  because  my 
deriniticn  is  right  and  yours  cannct  possibly  have  any 
merit . 


Ir  the  context  of  this  report,  distributed  computing 
is  used  in  the  broad  sense  which  includes  systems  which  are 
at  one  end  of  the  spectrum  completely  uncoupled  and  at  the 
ether  end  of  the  spectrum  very  tightly  coupled,  such  as 
multiprocessor  systems  which  share  some  memory.  In  short, 
distributed  computing  refers  to  a computing  process  which 
separates  a task  into  two  cr  more  individual  tasks  carried 
cut  by  two  cr  more  processors. 

In  the  case  of  the  Navy  airborne  tactical  systems, 
the  Ao-E  toe  A7-E-D,  the  P-3C  would  not  be  distributed 
systems,  whereas  2-2C,  S-3A  and  F-14,  f-ld  would  be 
distributed  systems. 

Some  of  the  terms  frequently  used  tc  refer  tc  such 
systems  are  federated  or  dispersed  systems.  The  term 
federated  connotates  a certain  structural  hierarchy  sc  that 
cne  computer  acts  as  the  executive  and  others  are 
subservient  computers.  The  term  dispersed  connotates 
physical  dispersal  or  distance  between  the  processing 
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deients.  In  our  use  of  the  term  distributed,  no 

connotations  of  this  type  are  implied.  If  we  wish  to 
discuss  physically  dispersed  processing  concepts,  we  wculd 
rerer  to  such  distributed  systems  as  physically  dispersed 
distributed  systems.  In  our  use  of  the  term,  distributed 
processing  dees  not  imply  that  the  processing  elements  are 
in  any  sense  coequal  and  homogeneous  in  structure.  he  wculd 
call  such  systeas  physically  homogeneous  distributed 
systems.  Physically  homogeneous  distributed  systems  can  be 
cqamzed  into  logically  hierarchical  distributed  systems 
where  one  processing  unit  may  assume  the  role  cf  the 
executive  and  the  others  as  subordinates,  clcsely  modeling 
the  military  hierarchy.  Systems  which  contain 

ncnhomogercccs  processors  are  called  heterogeneous. 

Iha  following  binary  tree  summarizes  cur 
nomenclature  and  taxonomy. 

Eigital  computing  Systeas 

I.  Ncndistnbuted 

II.  Cistrituted 

A.  Het erogeneous 

1)  Logically  hierarchical 

2)  Logically  cf  egual  rank 

£ . Homogeneous 

1)  Logically  hierarchical 

2)  Logically  cf  equal  rank 

Each  of  the  categories  can  be  either  physically 
close  or  dispersed. 

A dedicated  computing  system  is  one  in  which  the 
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same  set  ci  tasks  is  executed  over  and  ever  again.  The 
contrasting  situation  occurs  at  university  computing  centers 
where  a task  stream  is  constantly  changing  and  where  tne 
same  program  is  seldom  executed  more  than  cnce. 


2.  Current  i'  r t n d s In  Airborne  Tactical  Systems 

Ibe  F- 16  and  F-16  show  a trend  away  trom  the  single 
central  processor  systems.  Distributed  systems  in  cne  ferm 
cr  another  is  the  apparent  trend.  Also,  these  systems  are 
heterogeneous  m that  several  types  of  computers  are  used. 

Ihere  is  a natural  force  toward  het ercgenecus 
systems  because  the  airborne  systems  manufacturers,  who  act 
as  the  majer  contractor  usually  hire  subcontractor s for 
subystems:  radar,  electronic  warfare,  communications  etc. 

Each  of  these  subcontractors  probably  has  a different  LSI 
computer  which  they  prefer  to  use.  To  force  them  to 
redesign  a system  using  a different  computer  would  naturally 
increase  the  contract  cost.  Optimization  cf  the  contract 
cost  tenus  tc  encourage  processor  diversity. 

from  the  point  of  view  or  life  cycle  costs, 
diversity  of  computers  creates  substantial  additional  costs, 

namely 

1)  Stocking  line  removable  units  for  each  type  of 
computer  at  the  repair  station. 

2)  Documentation  for  each  uistinct  unit  must  exist 
at  repair  stations. 

J)  A service  person  must  either  go  to  several 
different  schools  in  order  to  learn  to  service  different  I 
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systems  ct  different  service  personnel  for  each  distinct 
computer  type  is  needed. 


4)  Software  upkeep  costs  for  the  diverse  systems 
will  also  become  higher  again  because  of  documentation  and 
personnel  education  costs. 


Our  cost  analysis  will  show  the  penalties  the  Navy 
has  to  pay  eventually  if  the  objective  or  the  project  is  to 
minimize  tne  acquisition  costs  of  the  systems  only. 


3 . ten e fits  Of  Homogeneous  Systems 

'Ihe  most  important  benefit  of  homogenous  systems  is 
tnat  human  beings  who  are  designing,  servicing  and  using 
such  systems  need  tc  only  learn  one  system.  The  human 
effort  tc  design,  service  and  use  computers  is  definitely 
the  most  costly  item  in  any  system.  Many  chips  of  computer 
hardware  can  be  bought  for  the  daiiy  wage  cf  a hardware  or 
software  service  engineer.  Concern  for  minimizing  computer 
memory  by  clever  programming  techniques  is  cniy  economical 
when  a large  numrer  of  identical  systems  are  designed.  To 
try  to  isolate  a hardware  problem  to  anything  other  than  the 
computer  itself  is  scon  becoming  obsolete.  How  many  of  us 
bring  a hand  held  calculator  to  a serviceman  to  fix  it? 
Eecause  a new  calculator  costs  $20,  no  technician  can  affort 
to  spend  more  than  hall  an  hour  to  service  it. 

Proliferation  of  LSI  computers  at  this  point  in 
history  is  unavoidable.  Any  new  revolutionary  development 
will  attract  many  groups  whc  are  trying  to  share  in  the 
profits  and  who  cannot  afford  to  spend  time  worrying  about 
standards.  Being  first,  establishing  a reputatior  and 
staying  first  is  more  important  and  more  effective  in 
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establishing  standards  than  spending  endless  hours  trying  to 


reach  a compromise. 

It  is  however 

already  clear 

that 

proliferation 

of 

micr ocom  puters 

is 

ending. 

Many 

manutact  urers 

rind  that  they  are  too 

late 

or  offer 

too 

little,  and 

many 

have  already  closed 

their 

doors,  cr 

sold 

cut,  or  merged 

with 

ethers.  The  defactc 

standards 

are 

teeing  established. 

Although  the  proliferation  of  LSI  ccaputers  creates 
a tendency  to  have  heterogeneous  systems  the  homogeneous 
systems  have  substantial  benefits.  Tc  add  onto  a 
homogeneous  system  requires  typically  adding  another  board 
into  an  empty  slot.  Tc  isolate  problems  can  be  dene  mere 
easily  because  swapping  identically  functioning  replaceable 
units  is  a very  simple  and  widely  used  technique  for 
troubleshooting. 

It  is  not  hard  to  convince  oneself  that  homogeneous 
systems  have  many  advantages  over  heterogeneous  ones.  The 
guest ion  is,  how  can  one  push  effectively  against  the 
natural  trend  of  unique  devices  which  nas  developed  in  the 
avionics  industry. 

A solution  is  to  encourage  two  trends  which  are 
developing  naturally  among  LSI  computer  manufacturers.  one 
trend  is  the  mutual  agreement  by  several  companies  to 
manufacture  the  same  product.  The  SOS 0 is  manufactured  by 
several  companies  including  Texas  instruments  and  INTEL. 
Ine  ether  trend  is  toward  single  board  plug  to  plug 
ccmbatibility . The  SSC9900  and  tae  SBC60SC/ 10/20  are  plug 
to  plug  compatible  even  though  they  are  manufactured  by 
different  companies.  If  the  Navy  chose  its  standards  to 
inoluda  the  "defacto"  industry  standards,  then  homogeneous 
systems  could  become  an  economic  reality  in  the  Navy 
avionics  computing. 
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V.  iJiiHODOiOGJf  FOR  ANALYSIS  OF  DISTRIJUIED  SY^IEKS 


A.  FLOAdRArHS 


1.  Introduction 

Complexity  cf  programs  has  received  considerable  attention 
troa  tne  theoretical  point  ct  view.  Ihe  ccirplexity  measure 
used  is  normally  the  number  ct  basic  operations  required  to 
compute  the  result. 

Another  significant  measure  of  program  complexity, 
namely  the  complexity  of  program  control,  has  just  recently 
received  some  attention  [17], 

In  this  report  to*-h  measures  cf  complexity,  the 
executicr  time  required  to  compute  tne  result,  and  pregram 
control  coaplexity  are  viewed  as  two  aspects  of  the  same 
problem.  Ey  the  use  of  graph  theory,  the  discrete  systems 
analysis  problems  arising  in  electrical  engineering  or 
hydraulics  engineering  are  shewn  to  be  abstractly  the  same 
as  those  arising  in  computer  programming.  The  tlowgraph 
which  is  used  to  describe  computer  programs  is  somewhat 
different  from  the  traditional  control  graph.  The  view  of 
flowgrapbs  presented  here  also  corresponds  tc  network  flow 
problems  for  wnich  there  is  a unit  cost  associated  with 
flows  through  an  arc.  In  Section  A. 2 the  abstract 
similarity  of  Discrete  Systems  Analysis  and  computer 

programs  is  pointed  out.  In  Section  A . 3 Kirchhot'f's  laws 
are  applied  tc  derive  basic  relationships  which  describe  the  | 
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tehavior  or  the  discrete  systems.  These  relationships  arc 
dependent  cn  the  structure  or  the  system  only  ard  are 
applicable  to  all  discrete  systems  which  car  be 
caaracter iaed  ay  a dual  set  of  variables  called  the  flew  and 
potential  variables  respectively.  Section  A. 4 shows  hew  the 
techniques  tsed  to  solve  discrete  systems  problems  are 
equally  applicable  to  determine  execution  time  values  in 
program  seqments.  Section  A. 5 derives  an  expression  fer  the 
total  execution  time  in  terms  of  independent  flow 
parameters.  A summary  is  presented  in  Section  A. 6. 


2.  Abstract  Similarity  of  Discrete  systems 


in 

this 

sect  ion 

we  introduce 

a vi 

ew  of  programming 

which  shews 

t he 

acst  ract 

similarity 

of 

the  programming 

problem  to 

the 

prob leras 

in  engineering 

and  operations 

analysis . 

For  a 

complete 

trea  tment 

of 

discrete  systems 

arising  in 

engineering  , [ 1 

2 ] and  [ 1o  ] 

are  e 

xcellent  sources. 

Fetecence  [7]  treats  the  problems  in  network  flows. 

figure  V.A.1  illustrates  three  discrete  systems 
arising  rrca  electrical  engineering,  Hydraulics  and  computer 
programming. 

ke  view  the  three  discrete  sytems  as  a collection  of 
two  terminal  elements  such  as  batteries,  resistors,  current 
generators,  or  pumps,  constrictions  in  pipes  and  flow 
generators,  or  sequences  of  computer  program  statements, 
control  statements  and  start  and  termination  statements. 
Ihe  way  in  which  the  two  terminal  elements  are  ;cincd 
together  gives  rise  to  a connected  system  ct  two  terminal 
elements  which  may  be  described  by  the  graph  in  figure 
2. 
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In  figure  V.A.1 (a)  the  vertex  represents  the 
terminal  cf  resistor  R ^ which  is  joined  tc  the  positive 
terminal  cf  the  battery.  Arc  represents  the  two  terminal 
resistor  K . The  remaining  correspondences  are 

d y : K , a : R^,  a^  : I (t)  , a^  : R^,  a^  : V ( t ) 


where  I(t)  represents  the  current  generating  element 
and  V ( t ) represents  the  voltage  source. 


In  an  analogous  way  the  syaiboi  X represents  a pump 
whose  one  terminal  is  at  a hicher  pressure  than  the  ether 
and  is  connected  tc  the  constriction  C^.  Therefore,  the 

arcs  again  represent  cor  responding  two  terminal  hydtaulrc 

e 1 <_  m m n t s . 


a : C , a : t , 

112  2 


a 

3 


C 

3 


i 


a : F (t)  , a : C , a : P (t) 
h 5 5b 


The  traditional  way  or  representing  program 
rlowcharts  ty  a directed  graph  has  been  to  associate 
tunctional  statements  with  vertices  and  control  paths  with 
arcs.  It,  cn  the  other  hand,  sequences  or  functional 
statements  are  associated  with  arcs,  and  control  points  m 
the  program  are  associated  with  vertices,  then  we  may  define 
the  concept  ot  a flowgraph  which  coincides  with  th*-  one  in 
figure  V.A.2.  The  arcs  a correspond  to  the  sequences  or 


statements: 


I 


Jk 
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a : SUM=0;  1=1; 
1 


d 

2 


SUfi=.SUM  + I*+J;  I<5; 


a : I<5  is  TRUE;  1=1+1; 


a.  : I<^  is  FALSE;  PBINT  SUM; 

5 

a : NO  OPERATION ; 

4 

A : END-START  SEQUENCE; 

b 

From  the  knowledge  of  the  characteristics  of  the  two 
terminal  elements  and  from  the  way  in  which  these  elements 
are  connected,  we  can  determine  the  behavior  of  the  system. 

There  are  two  complementary  variables  x(t)  anc  y(t) 
which  may  be  regarded  as  functions  oi  time  ard  which  play  a 
central  tele  in  discrete  systems  theory.  In  electrical 
engineering  x(t)  represents  voltage  differences  and  y ( t ) 
represents  currents.  The  two  terminal  element,  resistcr  R , 

is  characterized  by  tne  relation: 
x 1 (t)  =»**  y (t) 

It  the  resistance  value  K is  Known  and  if  tne 

1 

current  through  the  element  is  y^(t)  tnen  the  potential 
dirterence  across  the  element  will  be  x^(t).  Eacn  ot  tne 
six  two  terminal  circuit  elements  are  characterized  by  a 
relationship  of  this  type 
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x (t)  « y < t) , = R y^(t)  , 

x.  (t)  = R y (t) 

5 5 5 

Voltage  and  current  sources  are  specified  by 
relations 

x ( t ) = V(t)  , y (t)  = i (t) 

b 4 

We  should  note  here  that  inductive  and  capacitative 
elements  were  omitted  from  the  examples  fcr  simplicity,  a 
capacitative  element  would  have  the  characteristic 
relationship 

C d/dt  x(t)  = y (t ) 

Ihe  inductive  element  would  be  characterized  by 

L d/dt  y (t ) = x (t) 

A knowledge  cf  the  characteristics  or  the  two 
terminal  elements  and  knowledge  of  hew  they  are 
interconnected  allows  us  to  formulate  a linear  system  of 
eguations.  If  the  system  contains  two  terminal  elements 
which  have  a differential  relationship,  then  the  system  is  a 
linear  system  of  differential  equations.  In  programming 
applications  the  two  terminal  elements  are  equivalent  to 
resistors  and  hence  only  ordinary  linear  systems  arise.  In 
the  hydraulics  system  described  in  Figure  V.A.I(t)  the 
variable  x corresponds  to  pressure  and  the  variable  y 
corresponds  to  flow.  Depending  on  the  characteristics  of 
the  constriction,  we  may  formulate  the  relations 
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In  computer  programs,  each  sequence  of  instructions 

requires  a certain  amount  of  time  to  execute.  Therefore  we 

may  associate  the  execution  time  r with  each  execution 

i 

sequence.  Ihe  variable  y may  be  thought  of  as  the  rumber 

i 

of  times  the  execution  sequence  is  executed,  or  it  may 

represent  the  relative  frequency  or  probability  with  which  a 
particular  execution  sequence  is  executed.  Ihe  tonal  time 
that  a program  is  in  the  given  execution  sequence  therefore 
is  expressed  as 


x = T y 
i i i 


Here  I is  analogous  to  resistance,  y is  analogous 
i i 

to  current  flow,  and  time  consumed  by  the  program  segment  is 

analogous  to  the  potential  difference.  in  cur  example  in 
figure  V . A . 1 (c) 


a :x  = T y , a : x = r y, 

1 1 1 1 2 2 2 2 


a :x  = ly,a  :x  = T y, 
3 3 3 3 5 5 5 5 


a :x  = I y , a : x = T y 
4 4 446  o b b 


bl) 


----- - 


H € note  here  that  any  directed  cycle  in  the  piograa 

corresponds  to  a current  generator  in  electrical 

engineering.  He  must  know  something  about  such  cycles  in 

order  to  analyze  programs.  In  this  instance  we  can 

determine,  looking  at  the  program,  that  y is  executed  four 

4 

times.  If  we  are  interested  in  determining  the  total 

execution  time  for  executing  the  program  once,  then 

b 

y = 1 and  y = 4,  El  T y 

o 4 i=1  i i 

He  note  that  if  we  think  of  T as  a per  unit  ccst  of 

i 

flow  of  a certain  commodity,  then  the  above  fcruula 
represents  a network  flow  problem  with  costs,  where  in 

Figure  V.A.2  is  a source  vertex  ana  v is  the  sink  vertex 

5 

and  where  the  flews  y may  be  integer  constrained  in  case  we 

i 

think  of  y as  representing  the  number  of  tines  a giver  arc 
i 

is  executed.  If  we  think  of  y as  execution  frequencies,  or 

i 

execution  probabilities,  then  the  integer  constraint  is 
removed.  Arcs  may  have  capacity  constraints  such  as  a data 
dependent  lccp  which  is  maximally  executed  n-times. 


3.  Kir chof f j.s  Laws 


In  all  discrete  systems  cf  the  type  treated  here, 
the  Kirchhoff's  law  which  states  that  the  sum  of  the  flows 
intc  a vertex  is  equal  to  the  sum  of  the  flews  out  of  a 
vertex  is  applicable.  This  law  implies  that  the  flews  y 

i 

are  related  and  in  particular  that  (n— 1 ) of  the  variables 
may  be  expressed  in  terms  of  the  remaining  cnes,  where  n is 


b 1 


the  number  or  vertices  in  the  .graph.  References  [12]  and 
[1b]  develop  a systematic  way  of  expressing  the  sc-called 
tree  variables  in  terms  of  the  co-tree  variables.  The 
following  contains  a synopsis  of  that  development. 

Definition  1.  A spanning  tree  I of  a connected 
grapn  G,  of  n vertices  is  a connected  subgraph  which 
contains  all  n vertices  and  has  n- 1 arcs. 

Cne  spanning  tree  of  the  graph  in  figure  V.A.2  is 
given  by  the  heavy  arcs.  Each  remaining  arc  in  the  graph 
belongs  to  the  co-tree,  that  is,  the  complementary  part  of 
the  spanning  tree. 

Definition  2.  Let  us  consider  a graph  in  which  the 
directions  of  the  arcs  are  ignored.  Such  a craph  is  called 
an  undirected  graph.  If  a co-tree  edge  is  added  to  the 
spanning  tree  of  such  a graph,  a unigue  sequence  of  edges, 
known  as  a circuit,  is  formed.  This  circuit  consists  cf  the 
co-tree  edge  whose  terminal  vertices  v , v are  connected  in 

i j 

the  spanning  tree  oy  a subset  of  edges  in  the  tree.  The 

circuit  consists  of  the  sequence  ot  edges  a , a , a , a . 

b 1 2 5 

Each  co-tree  arc  added  to  the  spanning  tree  arcs  in  turn 

creates  a unigue  circuit  consisting  of  the  cc-tree  arc  and 
the  arcs  in  the  spanning  tree. 

The  totality  of  circuits  so  formed  constitutes  a 
basis  in  the  vector  space  of  all  circs. 

Definition  3.  Let  c = (x  ,x  ,...,x  ) be  a vector 

12  s 

whose  components  x consist  of  zeroes  or  ones  and  where  the 

i 

index  m represents  the  total  number  of  edges  ir  the 


1 


L 


undirected  graph.  A vector  c represents  a circuit  if  x 

i 

whenever  a is  in  the  circuit  and  x =0  whenever  a is  not 
i i i 

in  the  circuit.  Such  vectors  form  a vector  space  under 

componentwise  modulo  2 addition.  The  vector  space  is  called 
the  space  or  circs. 

Associated  with  the  flowgraph  in  Figure  V.A.2,  we 
nave  the  tasis  circuits 

ai  a2  a3  a4  a5  a6 

C1  (0  l 1 1 0 o\ 

Oj  \ 1 1 0 0 1 1 / 

Ihe  vectcr  space  of  circs  in  this  case  consists  of  tne 
modulo  2 sums 

c2  **  c2  ~ 1»  0 t*>  0,  0 ® 0,  1 tft  1 , 1 1) 

= (0,  0,  0,  0,  0) 

Cj  c2  = (1  0 1 1 1) 

The  total  number  of  circs  is  4 in  this  case,  or  more 
generally 

_ B 
1 • 

where 

M = E - (V  - 1)  = E-V  ♦ 1 

M is  called  the  cyclomatic  number,  E is  the  rumber 

b3 


i 


,A 


of  edges  in  the  graph  and  V is  the  number  cf  vertices 


The  concept  of  circs  remains  unaltered  if  we 
consider  the  direction  of  the  arcs  in  tne  circuit.  The 
direction  cf  the  co-tree  arc  induces  a direction  in  tne 
circuit  which  is  fcrmed.  By  adding  the  co-tree  arc  a in 


Figure  V.A.2,  the  arcs  a , a , a agree  with  the  induced 

12  5 

direction  and  hence  the  corresponding  vector  is 


c 


2 


a5 

1 


a6 

1 


) 


If  a were  directed  frcm  v tc  v then  the  induced 
6 15 

direction  of  the  circuit  would  be  opposite  of  arcs  a , a 

5 2 

and  a^,  nence  the  vector  would  be  represented  as 

al  a2  a3  a4  a5 
c2  = (-1  -1  0 0-1 


Although  the  signs  are  unimportant  in  mcdulo  2 
arithmetic  because  -1  = 1,  the  signs  become  important  when 
the  direction  cf  flows  is  considered. 


The  relationship  between  the  flew  variables  could 
have  been  obtained  by  applying  Kirchhoff's  laws  of  flow  into 
a vertex  is  equal  to  flow  cut  of  a vertex  at  n-1  vertices, 
be  have  chosen  to  express  the  relationship  by  usinc  the 
concept  of  circs.  The  result  provided  in  detail  in  [12]  and 
[ 16  ] is  as  fellows . 

Theorem  1.  The  tree  flow  variacles  can  be  expressed 
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in  terms  cx  the  co-tree  flow  variables  by  usinc  tl 
coefficients  matrix  whose  ccluans  correspond  to  the  sign* 
incidence  vectors  representing  the  basis  circuits. 


X11 

x12 

X21 

X22 

X31 

• 

• 

• 

• 

• 

xn  - 1 , 1 

• 

where 


if 

tree 

arc  i 

is 

if 

tree 

arc  i 

is 

in  circuit 

k 

if 

tree 

arc  i 

is 

in  circuit 

k . 

not  in  circuit  k 
positively  incident 

negatively  incident 


In  tne  flowgraph  in  Figure  V.A.2  the  relationship  of  t, 
spanning  tree  variable  is 


We  note  that  in  the  first  equation  above 


which  states  that  the  flow  cut  from  vertex  v 


is  eoual 


the  flow  into  vertex  v . 

1 


Cne  can  use  the  second  Kirchhcff's  law  for 
potentials  to  relate  the  co-tree  variables  to  the  tree 
variables.  In  any  circuit  in  the  network  the  sum  of  the 
potential  differences  is  zero. 


Theorem  2.  The  co-tree  potential  variables  can  be 
expressed  ir,  terms  of  the  tree  potential  variables  by  using 
tne  transpose  of  the  matrix  X in  Theorem  1. 


L1 

t 


c 

X1 

- 

X11 

X21 

x i i 
n- 1 , 1 

c 

x2 

= 

X12 

x2  2 ■ 

n-1 , 2 

c 

XM  J 

_ X1M 

X2M  * ‘ * 

x . .. 
n-1 , M 

x 


2 

‘n-1 


4.  Fro tie m Formulation  and  Solution 

we  shall  now  formulate  and  solve  the  three 
abstractly  similar  problems. 

In  the  problem  in  Figure  V.A.I(a)  we  have  the 
following  r e lationships  for  each  of  tne  twc  terminal  circuit 
elements. 


K 


\ 


w 


0 

0 

0 


0 

R.. 

4 

0 

0 


0 

0 


0 \ 


R3  o 


/ rl  \ 


(1) 


Ey  Kirchoff**  lavs,  flow  variables  are  relateJ  by 


bo 


and  the  potential  variables  are  related  by 


tremultif lying  (1) 


Using  (J)  on  the  left  and  (2)  cn  the  right 


expending  on  what  information  is  prescribed,  the  problem  can 

ce  easily  solved.  If  we  Knew  I = I (t)  and  v = V ( t ) , then 

4 o 

v and  I can  be  determined  in  terms  of  I (t)  and  V (t)  as 
4 t> 


fellows: 


4 

v ( t) 


V.  = 


I,  = 


(R2  + R3)  lit)  + R2Ib 
R2I  (t)  + (Rx  + R2  + R5)  Ifi 


v ( t ) - R2I(t) 
R1  + R2  + R5 


/ v(t)  - R2I  (t)  \ 
V4  = (R2  + R3*  I(t)  + R2  \ R!  + R2  + R5  / 


In  the  hydraulics  problem  in  Figure  V.A.I(t)  precisely  the 
same  results  would  re  obtained  if  the  flow  rate  F(t)  and  the 
pressure  difference  P(t)  were  prescribed. 


In  programming  problems  we  typically  know  the  flew 

values.  For  example,  if  we  execute  the  pregram  in  Figure 

V. A. 1(c)  once,  then  y = 1.  Because  the  loop  is  executed 

6 

exactly  feur  times  y =4  and  hence: 

4 


Here  x represents  the  total  execution  time  in  the  interior 

4 

loop,  whereas  x represents  the  execution  time  in  the 

o 

exterior  loop. 
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lhis  report  shows  that  discrete  systems  analysis  is 
analogous  and  applicable  to  the  analysis  of  conputer 
programs.  I he  traditional  view  of  flcwgraphs  [17] 
associates  vertices  with  blocks  of  code  and  arcs  with  the 
flow  of  control.  That  view  does  not  lead  to  tne 
correspondence  exhibited  in  this  paper. 

We  would  Hire  to  also  point  out  the  similarity  of 
the  flowgraph  analysis  to  the  problems  encountered  in 
network  flows  in  which  a unit  flow  through  the  aic  is 
associated  with  the  cost  [7], 

because  both  discrete  systems  analysis  and  network 
flow  ptobleits  are  highly  developed  areas  in  engineering  ana 
science,  the  tools  and  techniques  developed  in  these  areas 
become  applicable  to  computer  program  analysis. 

Program  analysis  software  development  which 
automates  the  analysis  of  programs  usinc  the  discrete 
systems  analysis  techniques  described  here  is  a task  which 
we  hope  to  encourage  by  this  segment  of  the  report. 


t.  DATA  UeWGHAPUS 


1- 


The  basic  inadequacy  in  program  cccumentat  ion  in 
both  flowchart  and  programming  languages  ten  is  that  both 
terms  concentrate  on  how  a problem  is  being  solved  rather 


. «... .. ..  .. 


than  what  the  problem  is. 

It  we  do  sign  a multiplier  either  in  harewara, 
rirmware  cr  sottware,  it  is  essential  tc  know  what  the 
proclem  is.  In  proving  correctness  or  programs  we  must 
first  state  what  the  problem  is  Letore  we  can  verity  that 
cur  method  of  solving  it  is  correct. 

There  are  three  major  ways  in  which  we  state  what 
the  problem  is: 

(1)  by  the  use  of  formulas; 

(2)  by  drawing  Doxes  and  joining  then  with  lines; 

(i)  ty  the  use  of  decision  tables. 

Formulas  have  the  advantage  that  we  have  leaned  to 
manipulate  tfcern  in  order  to  derive  eguivalent  expressions 
which  serve  to  simplify  the  problems.  Alsc,  formulas  can 
directly  and  easily  be  ccmmunicated  tc  computers  it 
compilers  are  available. 

Formulas  have  disadvantages  when  they  extend  ever 
several  lines  or  several  paqes,  or  when  a large  collection 
of  formulas  are  used  to  describe  a problem.  Computer 
designers  have  used  both  formulas  and  drawings  to  document 
the  designs.  IBM  is  a major  user  of  drawings.  resign 
documents  which  describe  computer  hardware  art  docmented 
with  box/line  drawings. 

Eox/line  drawinqs  have  both  advantages  and 
disad vanages . The  major  disadvantages  ot  these  documents 
are  that  we  must  relearn  to  nanipulate  the  drawings  in  cider 
to  simplify  them  and  that  we  have  no  compilers  tor  graphics. 
Generally  human  transcribers  are  used  to  translate  graphic 


pictures  intc  notation  under sta ndaole  tc  the  computer.  The 
computer  redraws  the  pictures  usually  losing  positional 
integrity  ter  both  boxes  and  lines  and  thus  losing  soaie 
(possibly  important)  information. 

The  major  advantages  of  box/line  drawings  are  that 
data  flew  can  be  explicitly  shewu  across  formulas, 
information  is  not  constrained  to  lines  (one-dimensional)  , 
and  levels  of  abstraction  are  conveniently  achieved  uy 
functionally  labelling  boxes  and  lines. 

This  segment  tormalizes  the  concept  cf  the  tox/line 
drawings.  Such  drawings  form  a bipartite  directed  craph, 
ti-digraph,  wnich  we  shall  also  call  a data  tlowqraphs. 

A pregram  flowchart  alsc  corresponds  to  a graph 
construct  called  a tlowgrapti.  Tc  each  execution  seguerce  in 
the  flowgraph  corresponds  a data  fiowgraph  which  describes 
at  a chosen  level  of  abstraction  what  happens  to  the  data. 

A sinilar  data  flow  analysis  is  carried  out  by  Allen 
and  Cocke  £ 1 ],  although  both  tneir  control  flow  anc  data 
flow  are  differently  conceived  and  applied. 

A control  complexity  analysis  wnich  makes  uses  cf  a 
control  tlow  graph  and  introduces  a complexity  measure,  the 
cyclomatic  cumber  of  the  control  flowgraph,  by  McCabe  [ 17), 
has  some  similarities  to  our  concept  of  the  flowgraph.  The 
flowgraph  ic  the  in  this  section  is  abstractly  the  same  as 
graphs  used  in  circuit  theory,  discrete  systems  analysis, 
and  cost  criented  network  flew  problems. 

S hue iderma n et  al  [21]  showed  experimentally  that 
rlowcharting  has  little  value  in  increasing  programmer 
productivity.  The  value  we  see  in  liowcharts  or  ilowerapns 
is  related  to  automated  computer  analysis  or  rigorithms. 


In  the  previous  segment  tne  flowgraph  corresponding 
to  the  flowchart  was  defined  and  shown  tc  be  abstractly 
identical  tc  similar  graphs  encountered  in  discrete  system's 
analysis.  In  Section  2 the  data  flowgraph  cerr espondi rg  to 
an  execution  seguence  in  the  flowgraph  is  defined.  Section 
3 illustrates  the  usefulness  of  the  concept  ty  applying  it 
tc  the  analysis  of  an  airborne  real  time  tactical  system 
(Ao-E) . Section  4 is  a summary  of  what  this  segment 
contains . 

2.  Eata  Flowgrajjns 

Although  the  flowchart  analysis  gives  us  an 
effective  way  of  determining  execution  times  and  the 
complexity  or  programs,  it  dees  not  give  much  information  on 
the  independence  cf  processes  or  hew  processes  can  be 
executed  simultaneously  without  interfering  with  each  ether. 
Ihe  concept  cf  data  flcwgraphs  helps  to  graphically  display 
what  happens  to  data,  how  data  is  transformed,  and  hew  one 
can  partiticr  the  process  into  subprocesses  with  a minimal 
need  of  data  transfers. 

We  illustrate  the  ideas  first  before  we  tornalize 

the  concepts.  Referring  back  tc  Figure  V. A, 1(c)  and  Figure 

V.A.2  consider  the  graph  consisting  of  arcs  a and  vertices 

i 

v . Each  arc  of  this  graph  corresponds  tc  an  instruction 
i 

sequence  which  carries  out  a computation  on  seme  input  data. 
(Cf  example,  arc  corresponds  tc  a typical  assembl) 

language  instruction  seguence. 
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with  each  operation  another  vertex  o^,  figure  V.B.1  in  a 

manner  used  by  digital  circuit  designers  ever  since 

computers  were  first  designed  and  raanuf act tred . We  connect 
the  data  item  to  the  operation  which  uses  the  data  item  as 
an  input  by  an  arc  directed  into  tne  operation  vertex.  Tne 
output  data  item  cr  items  are  connected  to  the  operation  by 
arcs  directed  away  from  the  operation  vertex.  The  graphs 
resulting  from  carrying  out  this  association  with  flcwcraphs 
are  graphs  which  contain  two  types  or  vertices,  where  arcs 
connect  data  vertices  to  operation  vertices  and  where 
operation  vertices  in  turn  are  only  connected  to  data 
vertices.  Such  graphs  are  known  as  bipartite  directed 
grapns,  cr  bi-digraphs  [2]. 


Fig.V.B.l  Two  Components  of  the  Graph  Corresponding 

to  the  Flowgraph  Arc  a^. 
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fcr  each  arc  in  the  flowgraph  he  construct  a 
corresponding  bi-digraph.  He  note  that  control  operations 
such  as  branch  or  halt  instructions  do  net  alter  anj  data 
and  hence  do  not  require  a correspondent  bi-digraph. 


SUM 

I 


Fig.V,B,2  Components  of  the  Data  Graph. 

He  next  determine  an  execution  sequence  cr  all  execution 
sequences  for  a given  flowgraph. 

«e  are  new  ready  tc  formalize  the  definition  of  a 
data  graph. 

Definition  J.  1.  A data  flowgraph  corresponds  tc  an 
execution  sequence  in  a flowgraph  as  follows.  Let 

S — (a  | a 0 . • • p a ) 

1 2 n 

be  an  execution  sequence  in  a flowgraph.  1c  each  arc  a , 

l 


i 


# • • • 9 


there  corresponds  a mapping  of  input  variatles  x^ 

x into  output  variables  y , y , ...,  y . This 
k 12m 

relationship  is  denoted  by  some  operation  c and 


1 

as  a subgraph. 


functional 

indicated 


If  one  or  mere  of  the  input  variables  of  o is  identical  to 

i 

an  output  variable  of  some  ether  operation  o^,  then  we 
identify  such  variables  by  the  same  vertex  in  the  data 

flowgraph.  Similarly,  if  there  is  a common  input  or  output 

variable  to  one  or  more  operations  o , we  identify  such 

3 

variables  by  the  same  vertex  in  the  data  flowgraph.  If  this 


procedure  is  successively  carried  out  for  each  arc  in  the 
execution  sequence  S,  the  resulting  graph  is  a data 
flowgraph  cf  S. 

i»€  have  given  so  far  very  simple  examples  to 
illustrate  the  idea  of  a data  flowgraph.  It  is  easy  to  see 
that  in  a complex  program  there  are  large  numbers  of 
execution  sequences  and  hence  data  flowgraphs.  Therefore 
this  method  cf  analysis  would  become  so  complex  that  it 
becomes  useless. 


fortunately  the  idea  of  a data  flowgraph  lends 
itself  very  naturally  to  levels  of  abstraction.  ke  can 
illustrate  this  with  the  exavple  wnich  comes  from  the  A6-E 


tactical  system. 


3.  An  Illustrative  Real  Time  System 

a.  Cata  Flcwgraph  Construction 

An  attack  aircraft  (A6-E)  tactical  system  is 
used  to  illustrate  the  flowchart  and  data  rlcvgraph  analysis 
techniques. 

Figure  V.E.3  illustrates  he  top  level  flowchart 
which  descrites  the  system's  operation.  After  a haidware 
checkout  and  initialization  programs  have  been  executed,  tne 
program  goes  into  the  infinite  loop  described  by  the 
flowchart.  In  this  system  the  executive  program  is  very- 
simple;  a sequence  of  tasks  is  executed  without  a set  of 
priorities.  The  task  is  bypassed  whenever  there  is  nc  need 
to  execute  it.  The  analog  inputs  from  the  sensors  are 
sampled  periodically  cased  on  a real  time  system's  clock. 


FIG.V.B.3  A6-E  TACTICAL  PROGRAM  FLOWCHART 


Cne  execution  of  the  infinite  loop,  that  is,  the 
transition  from  the  control  point  atove  Steering 
Commands . . • '•  to  the  control  point  below  Ballistics 
Calculations..."  in  Fig.  V.B.3,  may  be  regarded  either  as  a 
set  of  all  possicle  execution  sequences,  or  as  a single 
transition  cf  control.  if  we  regard  it  as  a single 
transition  cf  control,  then  we  can  represent  what  happens  to 
the  data  with  a single  data  flcwgraph  as  shown  in  Fig. 
V.E.4.  Ihis  repr esentation  corresponds  to  the  overall  view 
cf  what  the  program  does.  Each  data  set  vertex  represents 
data  items  which  serve  as  inputs  or  outputs  of  the  system, 
whereas  the  operation  carried  out  by  the  systea  is 
represented  ty  a single  vertex,  a box  in  which  the  operation 
is  described  in  English. 
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FIG.V.B.4  DATA  FLOWGRAPH  OF  THE  A6-E  TACTICAL  SYSTEM 

If  we  wish  to  consider  a more  detailed  view  of 
the  operation  under  the  same  transition  cf  control,  then 
each  distinct  execution  seguence  gives  rise  to  a data 
flowgraph  and  the  set  cf  all  such  data  flowgraphs  describe 
in  more  detail  what  the  single  flowgraph  expresses  ir  Fig. 
V.E.4. 


r 


The  Navigational  Subsystem  consists  of  eight  sequential 
steps  in  Fig.  V.3.5.  the  first  step  is  entitled  Air  Data 
Cuantities-1  in  Fig.  V.B.6.  This  flowchart  gives  the  finest 
level  of  detail  and  enables  a programmer  tc  translate  the 
flowchart  to  a higher  level  language  or  an  assembly  language 
program. 


FIG.V.R-'S  FLOWCHART  OF  THE  NAVIGATIONAL  SUBSYSTEM 
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Corresponding  tc  the  flowchart  in  Fig.  V.E.6  we 
construct  a flcwgraph  in  Fig.  V.B.7.  In  the  flowgraph  we 
have  distinguished  between  the  vertices  from  which  more  than 
cne  arc  issues.  The  latter  vertices  ate  symbolized  by  a 
small  diamond  indicating  that  several  execution  sequences 
emanate  from  that  vertex. 

we  also  distinguish  between  twc  types  of  arcs: 
cne  (symrclized  by  a square)  corresponds  tc  a statement 
which  permanently  alters  a data  value;  the  ether  (symbolized 
by  an  arrow)  corresponds  to  a transition  ic  control  which 
dees  not  permanently  alter  any  data  values. 

Ihe  heavy  arcs  constitute  a spanning  tree  cf  the 
flowgrapn  which  is  of  significance  in  execution  time 
analysis  as  well  as  control  complexity  analysis. 

Further  simplification  of  the  analysis  can  be 
obtained  by  subdividing  the  flowgraph  into  sc-called  control 
segments,  which  are  segments  of  a program  with  a single 
entry  and  single  exit.  The  control  segment  from  v^  to  v^  in 

Fig.  V.B.7  is  shown  in  the  flowchart  form  in  Fig.  V.E.6,  and 
in  the  flcwgraph  form  inV.B.S(a). 

As  before,  we  can  generate  a data  flowgraph 
which  describes  an  overview  of  what  takes  place  in  the 
control  segment,  as  shown  in  Fig.  V.E.10.  If  we  are 
interested  in  more  detail,  then  we  look  at  all  possible 
execution  sequences  which  are  desribed  as  a rooted  tree  in 
Frg.  V. 8.9(c).  Corresponding  to  the  six  possible  execution 
sequences,  there  are  five  distinct  statement  sequences  and 
their  corresponding  data  flowgraphs  in  Fig.  v.B.11. 
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FIG.V.B.10  DATA  FLOWGRAPH  OF  FIRST  CONTROL  SEGMENT 
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FIG.  V 


. B . 1 1 DATA  FLOWGRAPIIS  CORRESPONDING  TO  FIVE  STATEMENT  SEQUENCES 
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can  similarly  ha 


The  control  segment  v to  v 

5 7 

described  in  flowchart  form  in  Fig.  V.B.12.,  as  an  overview 

in  Fig.  V.B.13,  or  in  complete  detail  as  in  Fig.  v.F.14(a), 
(t)  . 


The  control  segment  from  v to  v is  shown  in 

7 15 

flowchart  form  in  Fig.  V.E.15  and  as  an  overall  data 

flcwgraph  in  Fig.  V.B.16.  The  overall  view  cf  the  entire 
page  and  how  the  control  segments  fit  together  is  displayed 
in  Fig.  V.B.17. 


If  a program  contains  a loop,  then  the 
corresponding  flowgraph  is  a repetition  of  llowgraphs  each 
of  which  describes  the  data  flew  for  a single  transition  of 
ccntrcl. 


(ie  wish  to  note  that  in  the  A6-E  tactical 
program  there  are  about  sixty  pages  of  r lo wcharts-some  less 
complex,  some  more  complex.  The  page  used  tc  illustrate  the 
data  flowgraph  concept  is  thus  a small  bet  sufficiently 
complex  example  to  illustrate  the  usefulness  in: 

4 a ) analyzing  parallel  processing, 

(t)  test  case  preparation, 

(c)  error  analysis, 

(d)  program  verification. 
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FIG.V.B.15  FLOWCHART  OF  CONTROL  SEGMENT  THREE 
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FIG.  V.B.16  OVERVIEW  DATA  FLOWGRAP1I  OF  SEGMENT  THREE 
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FIG.V.B.17  data  flowgraph  describing  three  control  segments  of 

AIR  DATA  QUANTITIES- 1 
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4.  Anal  vs is  of  Parallel  Processing 

The  main  concerns  in  distributing  a process  amcng 
several  computers  is  the  resulting  inefficiencies  introduced 
by  the  distribution: 

(1)  greater  communication  problems  tetween 
computers ; 


(2)  duplication  of  data  and  programs; 

(3)  imbalance  in  execution  times  and  program  size 
aacng  the  processors. 

Ihe  data  flowgraphs  allow  us  tc  explicitly  determine 
the  numter  of  data  elements  which  must  be  communicated  to 
ether  processes. 

In  Fig.  V.B.17  the  data  fiowgraph  shows  that  the 
Pressure  Altitude  Calculations  have  no  data  values  in  common 
with  the  Mach  Number  Calculations.  We  can  conclude  that 
these  processes  could  be  carried  out  in  different  computers 
completely  independently  without  creating  communications 
problems.  The  same  graph  also  shows  that  the  Effective 
Iemperature  Calculations  use  two  data  values  generated  by 
Mach  Number  Calculations  and  two  data  values  from  Pressure 
Altitude  Calculations.  If  a single  computer  must  solve  the 
problem,  then  eight  data  values  are  used  as  inputs  and  five 
values  are  used  as  outputs.  If  two  computers  are  to  solve 
the  problem,  and  if  Mach  Number  Calculations  are  done  in  one 
computer  and  the  Pressure  Altitude  and  Effective  Temperature 
Calculations  are  dene  in  the  ether,  then  the  communication 
problems  are  increased  by  the  two  data  values  which  must  be 
communicated.  Effective  Temperature  Calculations  may  not  be 
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started  before  dach  Number  Calculations  are  ready.  This 
causes  timing  problems  in  addition  tc  communication 

i i 

problems;  however,  data  flovgraphs  allow  the  analysis  of 
j both  problems. 

Cata  flowgraphs  reduce  the  distributed  system  design 
problem  to  a graph  partitioning  problem  with  side 
constraints.  Several  effective  algorithms  exist  for  solving 
that  problem.  Reference  [2]  reviews  the  published 
literature  cn  graph  partitioning.  The  side  constraints  may 
be  taken  to  be  program  size  and  maximal  execution  time.  The 
problem  then  becomes;  Partition  the  graph  into  a minimal 
number  of  partition  elements  so  that  the  number  of  arcs  cut 
is  minimized,  and  tne  bounds  on  program  size  and  maximal 
execution  times  are  satisfied.  The  problem  is  completely 

[ 

analogous  tc  the  hardware  partitioning  problem  for  creating 
aether-bear ds  in  computer  design.  the  mcther-board  design 
problem  had  to  satisfy  input-output  constraints  which 
permitted  only  a certain  maximum  number  cf  input-cutput 
connecticns  for  each  mother-beard,  as  well  as  a certain 
maximum  number  of  daughter-cards  on  each  mcther-board. 

5.  lest  Case  Preparation 

As  all  of  us  who  write  computer  programs  knew,  a 

program  is  seldom  correct  when  first  executed.  Therefore  it 

is  safe  to  assume  that  programs  contain  errors,  and  we  would 
like  to  generate  test  cases  which  are; 

(1)  exhaustive  enough  to  discover  all  errors; 

(2)  small  enough  in  number  sc  that  we  can 

effectively  test  the  cases; 

(3)  suggestive  of  what  must  be  done  to  »a*.e 

L " 

^ ■— rr.. — - 


ccrr ecticns. 

Computer  programming  is  in  many  ways  analogous  to  a 
lengthy  derivation  in  solving  calculus  problems.  The  way  in 
which  one  gains  confidence  in  a lengthy  derivation  is  by 
looking  in  the  answer  section  to  see  it  the  result  obtained 
agrees  with  the  one  given  in  the  book.  If  the  results 
agree,  then  we  usually  are  satisfied.  If  net,  then  we  try 
to  establish  equivalence.  Failing  that,  we  check  algebraic 
manipulations,  signs,  differentiations,  integrations,  etc. 
until  an  error  is  discovered.  If  we  work  cr  an 
even-numbered  problem  which  does  not  have  an  answer  ir  the 
tack  of  the  book,  we  resort  to  different  schemes.  If  we 
trust  a friend  we  call  him  to  find  out  what  result  he 
ectained.  If  the  results  do  not  agree,  we  check  back  to  see 
when  the  results  first  disagreed. 

In  programming  we  use  similar  techniques.  We  write  a 
program  in  seme  higher  level  language  such  as  FORTRAN.  If 
we  write  a special  purpose  routine  to  evaluate  a 
trigonometric  function,  we  compare  our  results  with  the 
corresponding  library  routine.  how  many  test  values  dc  we 
use?  If  we  have  a polynomial  of  degree  n,  then  theory  tells 
us  that  n«-1  points  are  sufficient  to  establish  identity.  By 
using  a random  number  generator  to  generate  a set  of  n+1 
random  numbers  in  the  interval  of  interest  and  by  finding 
that  the  results  agree  with  sufficient  accuracy,  we  become 
confident  that  nc  further  errors  exist.  We  remain  confident 
until  someone  discovers  that  for  a particular  case  the 
results  are  incorrect.  We  fix  the  program  and  add  these 
particular  cases  to  our  repertoire  of  test  cases.  Usually 
the  endpeints  of  finite  intervals,  zero  value,  or  undetected 
underflows  and  overflows  are  a cause  of  trouble.  How  does 
the  data  flowgrapn  concept  help  us  generate  test  cases? 

We  ctserved  in  the  previous  segment  that  the  control 

94 


f 


sequent  w to  v had  six  different  execution  sequences  and 
d 5 

five  difrerect  statement  sequences.  Each  statement  sequence 

gives  rise  to  a different  function.  Iherefore  we  irust 
prepare  at  least  five  different  data  sets,  one  fcr  each 
function.  As  shown  in  Fig.  V.B.11  each  function  is  a 
constant  function,  and  hence  theoretically , cne  data  value 
tor  eacn  data  set  would  be  sufficient  to  check  identity  to  a 
previously  computed  constant  function. 

If  cne  considers  the  flowgraph  in  Fig.  V.B.7  in  its 

entirety,  then  the  tctal  number  of  execution  sequences 

tetween  v and  v is  72.  The  numoer  of  execution  sequences 
0 15 

may  be  calculated  by  a vertex  labelling  algorithm  which 
labels  each  vertex  with  the  number  of  distinct  access  paths 
from  the  entry  pcint. 

Because  several  execution  sequences  give  rise  tc  the 
same  statement  sequence,  cnly  50  distinct  statement 
sequences  exist.  If  each  statement  sequence  yielded  a 
unique  function,  we  would  have  to  construct  at  least  50 
different  data  sets,  each  data  set  containing  at  least  one 
set  of  values.  In  the  A6-E  tactical  program  there  are  b0 
pages  or  flowcharts  of  control  complexity  with  about  an 
average  or  20  statement  sequences  each.  Therefore,  there 
are  approxi  lately  (2C)*°  statement  sequences  in  the  entire 
program.  If  each  statement  sequence  gave  rise  tc  a 
different  function,  we  would  have  to  generate  (20) data 
sets,  each  containing  at  least  one  set  cf  data  values. 
Clearly  testing  the  program  would  become  impossible. 

Ihe  data  flowgraph  corresponding  tc  the  control 

segment  (i.e.  a program  segment  with  a single  entry  and  a 

single  exit)  from  v tc  v in  Fig.  V.6.10  is  d'sccncected 

0 5 
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£ r ojs  the  data  flowgraph  for  the  next  control  segment.  This 

means  that  the  two  functions  are  independent  and  can  be 
tested  independently  from  each  ether. 


1 fcecretically , the  first  control  segment  requires  5 
data  sets,  the  second  2 data  sets.  Altogether  5+2  data 
sets  are  necessary  instead  of  5*2  = 10. 


The  third  control  segment  is  a rational  function 
containing  5 statement  sequences.  Hence  5 data  sets  would 
need  to  te  constructed  to  test  out  that  function. 


In  order  that  two  rational  functions  te  identical, 
S1/H2  = 01/C2 

it  is  sufficient  tc  form  the  product  polynomial, 

S 1 * Q2  = Q1  * R2 

If  the  twe  product  polynomials  are  equal  fer  all  values 
except  possibly  the  points  at  which  the  denominators  vanish, 
then  we  car  conclude  that  the  rational  functions  are 
identical.  In  the  above  example,  four  data  values  per  data 
set  would  ce  sufficient.  Thus  5 + 2 ♦ 5 = 12  data  sets  are 
surficient  tc  test  the  identity  of  the  functions  calculated 
in  the  flcwgraph  in  Fig.  V.3.7  instead  of  the  50  data  sets 
estimated  on  the  basis  of  the  statement  sequences  in  the 
f lowgrapfc . 

Ihe  flowchart  page  used  in  this  example  has  average 
complexity.  If  we  assume  that  the  complexity  of  each  page 
is  on  the  average  similar  to  this  page  and  that  data 
flowgraphs  exhibit  the  same  degree  of  independence  as  they 
do  on  this  page,  then  only 
6C  * 12  = 720 

data  sets  need  to  be  constructed  instead  of  (20) 60 . Clearly 


9o 


6-  Error  Analysis 

The  data  flovgraphs  lend  themselves  to  numerical 
error  analysis.  Dorn  an  McCracken  [ij  presect  an  elementary 
tut  complete  treatment  of  roundoff  error  propagation  for 
hath  fixed-point  and  floating-point  arithmetic.  They  use 
data  flowgraphs  (or  process  graphs  in  their  terminology)  to 
develop  the  error-bound  estimates  for  each  function.  We 
shall  net  repeat  their  presentation  here  but  refer  the 
reader  to  their  beck. 

In  addition  to  numerical  error-bound  analysis,  data 

flovgraphs  give  strong  indications  of  possible  trouble  spots 

cr  errors  in  the  program.  For  example,  in  the  statement 

sequence  S S S in  Fig.V.  B . llyariable  M is  set  to  M in 

247  n-1 

£ and  rest  to  M in  S S . Althougn  the  function  may  be 
2 m-1  4 7 

correctly  calculated,  it  is  dene  clearly  in  an  inefficient 

fashion.  It  is  not  hard  to  reconstruct  the  program  to 
eliminate  this  inefficiency  and  still  compute  the  same 
function . 


7 • Program  Ye rif ication 

Fcr  real  time  tactical  systems,  pregram  verification 
is  particularly  difficult  to  accomplish.  In  order  to  verify 
that  a program  does  what  is  intended,  there  must  be  an 
unambiguous  statement  of  intention.  Frequently  the 
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statement  cf  intention  is  in  a flcwcnart  form.  Because 
flowcharts  imply  a sequence  cf  statements  and  a sequence  of 
controls,  the  statement  of  intention  not  only  specifies  what 
is  wanted,  but  also  in  what  sequence  it  should  occur.  This 
cver-specifies  the  program,  causes  ine f f icie rcy , and  removes 
useful  flexibility. 

Erogtam  verification,  as  described  by  Hantler  and 
King  [10],  consists  of; 

(1)  stating  formally  what  assumptions  are  made  about 
input  variables  before  entry  into  a procedure; 

(2)  asserting  algebraically  or  by  logical  statements 
wnat  the  output  variables  will  contain  when  the  procedure  is 
completed ; 

( 3)  symbolically  executing  the  program  as  described 
in  some  programming  language  to  show  that  the  results  agree 
with  the  specification.  The  data  flowgraph  is  a graphic 
expression  cf  one  or  more  algebraic  statements.  Therefore 
algebraic  statements  can  be  interpreted  into  data 
flowgraphs.  This  allows  us  to  construct  a data  flowgraph  or 
a set  of  data  flowgraphs  for  the  specification  statement. 

The  symbolic  execution  cf  a program  is  equivalent  to 
the  process  of  constructing  a data  flcwcraph  for  each 
execution  seguence  in  the  program.  The  verification  process 
is  the  process  of  checking  whether  or  not  the  data 
flowqraphs  corresponding  to  the  specification  are  equivalent 
to  the  data  flowgraphs  obtained  from  the  execution 
sequences . 

An  automated  process  of  showing  equivalence  is  by  nc 
means  an  easy  process  to  construct.  Conceptually,  however, 
data  flowgraphs  will  enhance  program  verification. 
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d.  Summary 


This  segment  introduces  the  data  flcwgraph 
useful  tool  in  the  analysis  of  real  time 
mere  applications. 


as  a 

Although  tnere  are 
fccused  attention  cn 
particularly  useful  in  systems  analysis: 


ccncept 
y stems, 
this  segment  has 


four  applications  which  are 


(1)  process  partitioning  into  sutprocesses  for 
distributed  processing; 

(2)  generating  test  cases  to  establish  that  the 
program  under  design  is  identical  to  a known,  correctly 
functioning  test  program; 

(3)  numerical  error  analysis  and  the  analysis  of 
inef f iciences  occurring  in  the  program; 

(4)  program  verification. 

Ihe  data  flowgraph  is  useful  conceptually  as  well  as 
in  the  practical  domain  of  implementation  of  algorithms  to 
carry  out  the  automated  analysis  tasks. 


C. 


EXECUTION  TIME  ES2IMATING 


In  Section  V.A  the  theoretical  aspects  cf 
estimating  were  given.  An  analysis  tool  whic 
formula  for  execution  times  in  terms  cf 
independent  flow  variables  could  be  developed 
program  compilation  process.  Presently  this 
a vailaole . 


execution  time 
h generates  the 
the  linearly 
as  part  cf  the 
tool  is  not  yet 
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Our  analysis  tor  the  Ab-E  operational  flight  program  was 
carried  out  ty  manual  methods.  The  entire  flowchart  cf  the 
program  is  a collection  of  flowcharts  one  per  page.  The 
majority  of  the  pages  contain  a single  entry  point  and  a 
single  exit  pcint.  By  looking  at  the  operations  indicated 
by  formulas,  it  is  not  hard  to  determine  aaicng  all  possible 
execution  seguences  the  one  which  consumes  the  maximum 
amount  of  execution  time.  It  is  that  one  which  was  used  to 
estimate  the  worst  case  execution  times  for  each  page  of 
flowchart.  An  upper  bound  fcr  the  worst  case  execution  time 
can  be  obtained  by  summing  the  maximal  execution  times  of 
each  program  segment.  It  may  be  that  such  an  execution 
sequence  is  never  realized  in  practice  and  therefore  the 
upper  fccund  measure  is  pessimistic.  Ibis  is  a way  or 
insuring  that  the  program  execution  never  exceed  the  upper 
bound  value.  The  values  in  the  tables  for  the  Ao-E 
operational  program  were  generated  in  this  way.  The 
breakdown  into  fixed  point  and  floating  point  operations  was 
chosen  Because  floating  point  hardware  units  are  presently 
available  fcr  LSI  computers  at  a low  cost.  Using  floating 
point  aritnmetic  enhances  accuracy  and  makes  programming 
easier . 


C.  FRGGBAM  AND  DATA  REQUIREMENTS 


In  order  to  determine  program  length  requirements,  each 
page  of  the  At>-E  operational  program  flowchart  was  used  and 
the  number  of  instructions  estimated.  Because  the  actual 
Ao-E  program  does  net  use  floating  point  arithmetic  the 
estimated  pregram  length  differs  somewhat  from  the  actual 
program  length.  A floating  point  instruction  does  not 
require  shifting  operations  because  this  is  done  in  the 
hardware  processor.  Consequently  the  actual  program  length 
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is  about  20X  longer  than  our  estimate  predicts. 

The  data  requirements  for  our  estimates  Ker°  based  on 
the  number  cf  variabes  used  in  the  programs.  The  floating 
pcint  format  is  assumed  to  be  a 32  bit  form  used  by  the  IBM 
computers  as  well  as  the  LSI  computers.  For  the  presently 
available  LSI  computers,  the  floating  point  unit  is  treated 
as  an  input-output  device  accessible  cn  the  systems  data 
bus.  The  constants  are  also  accounted  for  in  the  totals. 


For  distributed  systems,  it  may  be  more  efficient  from 
the  execution  time  and  bus  use  point  cf  view  to  duplicate 
constants  and  function  subprograms  in  each  of  tne 
processors.  In  our  analysis  we  have  assumed  that  this  is 
done.  Furthermore,  each  processcr  will  alsc  have  a small 
operating  system  which  also  is  duplicated  in  each  single 
board  computer.  Although  this  is  not  necessary  in 
distributed  systems  design,  it  is  dene  to  create 
independence  of  each  processcr  cn  the  bus.  The  failure  of 
any  single  beard  computer  will  not  cause  the  failure  cf  tne 
system. 


£ . PARTITIONING  METHODOLOGY 

The  logical  cchesiveness  of  a program  is  shown  by  the 
data  flow  analysis.  The  data  flow  analysis  allows  us  to 
determine  precisely  these  variables  which  must  be  shared  by 
ether  segments  of  the  program.  This  analysis  was  carried 
cut  painstakingly  for  the  A6-E  operational  pregram. 
Development  of  software  tools  to  make  this  analysis 
automatic  and  part  of  the  compilation  process  is  very  useful 
fer  the  partitioning  process. 
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Each  variable  was  considered  and  its  cccurrance  cn  any 
page  or  the  flowchart  was  recorded.  If  the  variable 
occurred  only  on  one  page,  once  as  an  output  variable  and  at 
least  once  as  an  input  variable,  then  that  variable  was 
defined  as  an  internal  variable  to  the  page.  A group  of 
pages  which  have  many  variables  in  common  with  each  ether 
and  few  variables  which  are  used  externally,  ferm  a 
logically  cchesive  program  segment.  For  example,  the  nine 
pages  which  constitute  the  navigational  module  have  IdJ 
variable*  in  total  and  50  of  these  are  external  tc  tne 
module.  Such  a module  is  a logically  cohesive  module. 

Our  partitioning  methodology  was  based  cn  the  concept  of 
this  logical  cohesiveness.  Logical  cchesiveness  is  a 
natural  byproduct  of  a well  written  program.  The  data  flow 
analysis  allows  us  to  discover  logical  cohesiveness  even  in 
a program  which  is  not  written  with  that  in  mind, 
furthermore,  logical  cohesiveness  reduces  the  number  of 
variables  which  are  transmitted  to  other  processes. 
Therefore,  the  bus  use  is  minimized,  or  egui valentl y,  the 
parameter  coint  passed  to  subprograms  is  minimized.  There 
may  be  other  considerations  of  importance  in  the 
partitioning  process.  If  we  wish  to  design  systems  which 
continue  to  function  even  when  one  ot  the  processors 
malfunctions,  then  a simple  way  of  accomplishing  this  is  to 
place  a process  in  more  than  one  processor.  This  is 
analogous  to  having  a pilot  and  copilot  cn  a commercial 
airliner  for  safety.  All  the  vital  functions  can  be 
distributed  so  that  the  failure  of  any  one  processor  will 
net  cause  failure  of  any  vital  function. 

Program  and  data  length  also  must  be  considered  in  tne 
partitioning  process.  If  programs  and  data  are  tc  be 
distributed,  it  is  important  that  the  progiam  and  data  fit 
into  the  computer.  Although  expansion  ot  memory  is  easily 
achieved  with  the  LSI  architectures,  the  access  time  tc  the 
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distributed  so  that  each  process  can  be  executed 
successfully  a prescribed  number  of  times  per  second.  This 
cf  course  is  a very  important  aspect  of  real  time  systems. 
All  cf  the  atove  considerations  are  used  in  the  partitioning 
process . 
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VI.  FUNCJiON AL  DESCFIiTION  OF  THE  V^TOL  SYSTEM 


we  develop  the  functional  requirements  for  the  VSTOL 
system  ty  examining  in  detail  the  avionics  system  fcr  the 
Ao-E.  Other  existing  systems  A7-E,  P3-C,  S3-A,  F-15,  and 
F-18  are  contrasted  with  respect  to  the  A6-E.  We 
characterize  the  functional  requirements  in  terms  of 
arithmetic  complexity,  control  complexity, 
intercommunication  requirement,  program  size,  and  data 
storage  size.  <Je  identify  the  core  elements  of  tactical 
systems,  that  is,  these  functional  elements  which  all  cf  the 
systems  share.  Two  of  the  VSTJL  applications  fighter/attack 
version  and  the  antisubmarine  warfare  version  are 
functionally  quite  different.  However,  the  functional 
similarity  of  the  VSTCL  versions  to  their  corresponding 
fixed  wing  cousins  is  great.  The  essential  difference 
tetween  VSIOL  and  iixed  wing  aircraft  is  in  the  takeoff  and 
landing  controls. 

A.  OVERVIEW  OF  THE  ATTACK  AIRCRAFT  TACTICAL  SYSTEMS 

The  primary  purpose  of  the  Navy  attack  aircraft  is  to 
provide  close  air  support  tc  forces  operating  on  land.  The 
Ao-E  and  A7-E  are  the  presently  employed  attack  aircrart 
which  use  an  on-board  computer  based  tactical  systen.  we 
have  chosen  the  tactical  system  of  the  Ao-E  as  a model 
because  its  documentation  was  most  easy  to  use  fcr  our 
analysis.  lhe  most  significant  functional  difference 
tetween  the  Ao-E  and  A7-E  is  that  the  A7-E  is  manned  ty  the 
pilot  alone,  whereas  the  Ao-E  has  a pilot  and  a 
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bcmtardier/navigatcr.  Both  systems  use  functionally 
identical  sensors  to  help  navigate  and  track  the  target. 
Ihey  are  designed  tc  carry  the  some  armaments  which  include 
free  fall  beets,  rockets  and  retarded  acceleration  weafens. 
Although  the  same  ballistics  problem  has  to  be  sclved  in 
both  cases,  the  numerical  techniques  or  doing  that  are 
different . 

We  describe  the  A6-E  system  in  sufficient  detail  sc  that 
cur  estimates  and  extrapolation  are  based  or  reality  rather 
than  on  an  assumed  hypcthetical  model.  The  Ac-E  system  is 
documented  in  two  documents,  one  which  describes  the 
flowchart  [Id]  and  the  other  which  describes  the  system 
functionally  [19].  The  assembly  language  version  cf  tne 
operational  flight  program  (OFP)  was  also  used. 


1.  AJ; | Tactical  System 

Ihe  operational  flight  program  performs  the 
following  fuctions: 

a)  Navigational  Calculations 

t)  Tracking  and  Ranging  Calculations 

c)  Ballistics  Calculations 

d)  Sensor  Input/Output  and  Steering 


a.  Navigational  Calculations 


Ine  sausors  used  to  generate  information  to  the 
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navigational  system  ace:  the  inertial  navigational 

equipment,  the  doppler  radar  equipment,  the  magnetic 

compass,  the  airspeed  indicator,  and  the  altimeter.  The 

intertial  navigation  subsystem  (INS)  contains  accelerooeters 

which  are  able  to  measure  accelerations  along  three  mutually 

perpendicular  axis  (x,y,z)  . These  measured  accelerat ions 

are  integrated  by  analog  circuitry  into  velocity  components, 

v , v , v which  ate  converted  uy  analcq  to  digital 
x y z 

converters  into  digital  information  which  is  placed  into 
computers  memory  at  the  fixed  rate  of  2d  times  per  second. 

Similarly,  the  Cep pier  radar  measures  analog 
information  which  is  converted  into  digital  information, 
namely,  the  velocity  component  along  the  ground  track,  and 
the  angle  between  aircraft  heading  and  the  ground  track, 
finally,  the  magnetic  compass  reading  is  converted  into 
digital  information  along  with  the  airspeed  and  altimeter 
readings . 


It  is  important  to  distinguish  between  accuracy 
and  precisicr.  Accuracy  would  be  a measure  associated  with 
how  close  the  reading  of  the  instrument  would  be  to  a 
carefully  calibrated  instrument.  The  precision  is  related 
to  the  number  of  binary  digits  which  are  generated.  The 
precision  of  the  instruments  is  12  binary  digits  or  less. 
The  accuracy  is  dependent  on  calibration  and  generally  is  10 
binary  digits  or  less.  There  are  systemic  errors  such  as 
the  Schuler  pendulum  effect  which  depends  on  how  carefully 
the  gyroscopes  are  stabilized  before  the  flight  takes  place. 
The  digital  systems  can  by  used  to  aid  in  the  calibration 
process  and  the  Schuler  pendulum  effect  is  partially 
neutralized  by  a digital  to  analog  signal  which  is  fed  tack 
tc  the  accelercmet ers. 

Unfortunately  errors  are  neither  random  nor  are 
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tney  purely  du»  to  bias,  therefore  it  is  net  possible  to 
improve  the  ton  binary  digit  accuracy  unloss  the  sensei 
instruments  are  improved.  Increased  accuracy  and  precision, 
however,  is  esritmely  expensive. 

The  navigational  system  operates  in  four  modes 
depending  on  the  centidence  that  the  pilot  and 
tear aidiei/na viga t 01  have  in  the  instruments.  If  the 
inertial  navigational  system  and  peppier  radar  are  loth 
operational  and  do  not  give  mutually  conflicting  data,  this 
aode  is  considered  most  accurate.  Ir  one  or  the  otlet  is 
suspected  or  inaccuracy,  the  two  more  modes  result,  inertial 
alone  or  Coppler  alone,  in  case  or  failure  of  both  systems, 
the  magnetic  compass  and  airspeed  with  a aaruai  correction 
tor  wind  velocity  is  used.  The  navigator  is  tne  backup  for 
all  tour  tod«s  failing. 

Ihe  computer  program  tor  the  navigational 
function  is  subdivided  into  nine  segments,  each  segment  is 
documented  as  a flowchart  page  as  well  as  two  to  five  pages 
ct  assembly  language  program.  We  have  extracted  from  each 
flowchart  page  the  basic  operation  counts  in  the  program. 

Because  the  io-L  computer  (IBM  4Fi)  has  no  floating  point 
arithmetic,  the  assembly  language  program  uses  scaled 
ar  it  time  t ic . In  the  flowchart,  however,  it  is  guite  clear 
which  variables  correspond  to  floating  point  numbers  and 
which  variable^  are  fixed  point  and/or  logical  variable:.. 

Iable  VT.1-&.  contains  the  breakdown  of  each  page  ct  the 
tlowenart  with  a ccunt  of  each  type  ot  instruction  as  well 
as  the  nusbei  ot  calls  to  library  subroutines.  The  two  rows 
corresponding  to  the  flowchart  page  are  the  mstnetiou 
counts  in  the  execution  path  which  would  fca  the  most  time 
consuming  execution  path  in  the  upper  row  and  the  total 
lustructicn  ccunt  on  the  page  in  the  lower  rev. 

Ihe  column  headings  refer  to  the  instruction  / 
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types  categorized  as  fellows  . 


epeunos 


tlowgraph 


C-conai tional  branch  for  integer  operands 


l/S-load  or  Store  an  integer 


tF-Conditicnal  branch  for  Floating  point 


ISF-Load  or  Store  a Floating  point  operand 


FAC- Floating  point  A Dd 


f J1U-F1  oating  point  Multiply 


FCV-Fl oating  point  Divide 


cC-COsine  functicn 


Sl-SIne  function 


AI-Arc  laugent  function 


L N- Logar  it hmic  fuNction 


S^-Stjuare  root  function 


KU-the  number  cf  independent  cycles  in  the 


ES-tho  number  of  distinct  execution  sequences  in 
toe  t io * graph 

1 he  last  two  columns  deal  with  ccntrcl 
complexity  measures  which  have  a close  relation  tc  tue 
number  or  tests  required  to  verity  program  identity  tc  a 
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given  program.  These  concepts  are  discussed  in  Chapter  V. 
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0 

9 
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6 
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40 
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0 

0 

0 

2 

0 

AIR  DATA2 

1 

7 

0 

23 

10 

7 

2 

2 0 

0 

0 

1 

2 

3 

2 

10 

0 

33 

14 

10 

2 

2 

0 

0 

0 

1 

AIR  MASS 
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3 

6 

29 

11 
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1 
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2 
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1 

10 
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4 

6 

6 

38 
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1 
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2 

0 
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DOPPLER 
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5 

0 
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16 

6 

0 

1 

1 

0 

0 

0 

5 

6 

VELOCITY 

2 

6 

3 

33 

17 

6 

1 

1 

1 

0 

0 

0 

SYSTEM 

4 

2 

0 

37 

10 

10 

1 

1 

1 

1 

0 

3 

6 

11 

VELOCITY 

6 

6 

0 

62 

16 

14 

2 

2 

2 

1 

0 

3 

BAP.O  IN 

2 

2 

3 

22 

9 

6 

2 

0 

2 

0 

0 

0 

8 

42 

VERT  LP 

4 

6 

5 

52 

11 

7 

3 

0 

2 

0 

0 

0 

INERTIAL 

2 

3 

0 

27 

11 

8 

2 

1 

2 

2 

0 

2 

1 

2 

ANGLES 

2 

3 

0 

27 

11 

8 

2 

1 

2 

2 

0 

2 

PLATFORM 

1 

3 

2 

36 

14 

13 

5 

1 

0 

0 

0 

0 

2 

4 

CORRECT1 

1 

7 

2 

40 

14 

13 

5 

1 

0 

0 

0 

0 

PLATFORM 

1 

1 

0 

58 

27 

22 

6 

1 

1 

0 

0 

0 

1 

2 

CORRECT 2 

1 

1 

0 

66 

31 

24 

8 

1 

1 

0 

0 

0 

TOTALS 

16 

35 

14 

288 

118 

83 

24 

8 

8 

5 

1 

7 

44 

9 

10 

28 

57 

19 

386 

136 

94 

32 

9 

8 

5 

2 

7 

TABLE  VI. 1 A6-E  NAVIGATIONAL 
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FAD 

FMU 

FDV 

CO 

SI 

AT 
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ES 

COMMAND 

3 

11 

0 

4] 

7 

3 

2 

3 

1 

0 

0 

0 

4 

9 

STEERING1 

4 

30 

0 

44 

7 

3 

2 

3 

1 

0 

0 

0 

COMMAND 

3 

3 

1 

39 

24 

7 

2 

1 

2 

2 

0 

0 

9 

40 

STEERING2 

5 

13 

4 

68 

31 

20 

5 

1 

4 

2 

0 

0 

COMMAND 

3 

13 

3 

35 

5 

6 

5 

0 

0 

0 

0 

0 

6 

32 

STEERING3 

3 

21 

3 

49 

6 

7 

5 

0 

0 

0 

0 

0 

SAMPLE 

0 

52 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

2 

INPUTS 

0 

56 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

INTERRUPT 

4 

20 

0 

4 

2 

0 

0 

0 

0 

0 

0 

0 

6 

9 

SERVICE 

9 

32 

0 

16 

7 

0 

0 

0 

0 

0 

0 

0 

STEERING 

4 

8 

1 

44 

10 

20 

1 

1 

1 

0 

0 

0 

6 

24 

DISPLAY 

5 

10 

1 

48 

12 

21 

1 

2 

1 

0 

0 

0 

DISCRETE 

0 

86 

2 

2 

0 

0 

0 

0 

0 

0 

0 

0 

2 

3 

OUTPUTS 

0 

90 

2 

2 

0 

0 

0 

0 

0 

0 

0 

0 

STEERING 

2 

10 

0 

6 

1 

1 

0 

0 

0 

0 

0 

0 

8 

10 

KEY  SEL1 

5 

31 

3 

22 

1 

1 

0 

0 

0 

0 

0 

0 

STEERING 

5 

6 

0 

18 

0 

2 

0 

0 

0 

0 

0 

0 

11 

22 

KEY  SEL2 

10 

19 

1 

66 

0 

3 

0 

0 

0 

0 

0 

0 

TOTALS 

24 

209 

8 

190 

49 

39 

10 

5 

4 

2 

0 

0 

53 

41 

302 

15 

315 

64 

55 

13 

6 

6 

d. 

0 

0 
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TABLE  VI.  2 A6-E  INPUT/OUTPUT 
AND  STEERING 
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ROCKET 

0 

0 

4 

49 

17 

19 

5 

ATTACK l 

1 

5 

4 

52 

17 

19 

5 

RlX'KET 

1 

18 

-} 

.14 

17 

13 

5 

ATTACK*’ 

1 

19 

> 

lb 

17 

13 

5 

BOMB 

> 

* 

4 

0 

lb 

2 

5 

1 

ATTACK l 

3 

5 

0 

JO 

5 

9 

1 

BOMB 

5 

5 

2 

4b 

21 

15 

b 

ATTACK-' 

5 

S 

4 

90 

2 1 

17 

b 

BOMB 

' 

> 

0 

79 

41 

19 

4 

ATTACK < 

) 

* 

l 

93 

4 1 

40 

4 

BOMB 

\ 

4 

4 

49 

2 J 

1 1 

> 

ATTACK 4 

\ 

5 

t> 

59 

2.1 

13 

> 

BOMB 

» 

) 

J 

17 

J 

1 

1 

ATTACKS 

1 

4 

6 

lb 

1 

3 

' 

BOMB 

4 

10 

b 

9 

J 

T 

1 

ATTACK*' 

(' 

14 

') 

27 

t> 

6 

1 

BOMB 

4 

4 

J 

JJ 

11 

12 

4 

ATTACK 7 

U 

11 

4 

76 

19 

14 

5 

COMMON  PKAv 

• « 

> 

0 

94 

41 

42 

3 

4 

1 

95 

41 

42 

1 

TOTAl-l 

24 

M 

24 

412 

191 

162 

32 

34 

47 

591 

I'lb 

1 7b 

14 
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ORE  AT  CIRC  00  0 46  10  13  4 4520001 

NAVIGATION  00  0 46  10  13  4 45200 


TRACK  RADR 

3 

7 

5 

23 

6 

6 

0 

0 

0 

0 

0 

0 

9 

10 

TESTS 

4 

10 

5 

27 

6 

6 

6 

0 

0 

0 

0 

0 

DEPR  ANGLE 

3 

4 

7 

21 

4 

3 

1 

0 

1 

0 

0 

0 

10 

147 

TRACK- 1 

3 

16 

7 

21 

4 

3 

1 

0 

1 

0 

0 

0 

TRACK  SCAN 

7 

13 

0 

44 

9 

14 

2 

4 

6 

2 

0 

0 

9 

35 

TESTS 

9 

21 

0 

51 

10 

14 

2 

4 

6 

2 

0 

0 

DEPR  ANGLE 

5 

9 

0 

11 

2 

2 

2 

0 

0 

0 

0 

0 

9 

20 

TRACK2 

9 

21 

0 

32 

10 

7 

4 

0 

0 

0 

0 

0 

LINE  OF 

2 

8 

4 

31 

9 

5 

4 

3 

1 

1 

0 

0 

8 

72 

SIGHT  RNG1 

3 

12 

5 

50 

10 

6 

5 

4 

1 

1 

0 

0 

LINE  OF 

10 

25 

2 

16 

2 

2 

0 

1 

1 

0 

0 

0 

13 

216 

SITE  RNG2 

10 

45 

3 

19 

2 

2 

0 

1 

1 

0 

0 

0 

j 

SHRIKE 

4 

14 

4 

36 

11 

9 

3 

3 

3 

1 

0 

1 

13 

17  \ 

! 

RANGING 

15 

39 

0 

25 

9 

3 

3 

1 

1 

0 

0 

0 

TOTALS 

41 

91 

22 

245 

60 

57 

19 

16 

18 

6 

0 

1 

86 

1013 

61 

193 

25 

323 

74 

64 

30 

17 

19 

6 

0 

1 

TABLE  VI. 4 A6-E  TRACKING  AND 
RANGING  FUNCTION 
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37 
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TABLE  VI. 5.  A-6E  TARGET  UPDATES 
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0 

0 

0 

0 

0 

ATTACK 

7 

11 

3 

15 

2 

2 

0 

0 

0 

0 

1 

0 

11 

33 

SELECT1 

8 

25 

3 

25 

6 

3 

1 

0 

0 

0 

1 

0 

ATTACK 

6 

23 

0 

22 

5 

5 

1 

1 

1 

0 

0 

0 

10 

72 

SELECT2 

10 

40 

0 

38 

7 

5 

1 

1 

1 

0 

0 

0 

STEP  OUT 

2 

2 

7 

15 

6 

1 

1 

0 

0 

1 

0 

0 

19 

102 

OF  ATTACK 

9 

19 

10 

18 

6 

1 

1 

0 

0 

1 

0 

0 

ATTACK 

5 

7 

10 

16 

4 

2 

0 

0 

0 

0 

0 

0 

17 

286 

VALID1 

6 

34 

11 

17 

5 

2 

0 

0 

0 

0 

0 

0 

ATTACK 

7 

9 

4 

24 

12 

2 

2 

0 

0 

0 

0 

0 

15 

84 

VALID2 

10 

20 

5 

39 

18 

3 

2 

0 

0 

0 

0 

0 

TOTALS 

65 

94 

24 

92 

29 

12 

4 

1 

1 

1 

1 

0 

142 

io17 

113 

290 

29 

144 

42 

14 

5 

1 

1 

1 

1 

0 

TABLE  VI. 6.  A6-E  ATTACK  DECISIONS 
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he  chose  floating  point  operations  to 
characterize  the  program  because  the  essential  reason  why 
floating  point  operations  have  not  been  used  in  tactical 
computing  has  been  that  hardware  floating  point  arithmetic 
has  been  toe  expensive  to  inplement.  The  expense  has 
changed  radically  with  the  LSI  chips  with  the  present  cost 
range  between  $200  - $5000  for  the  floating  point  unit.  The 
AN/UIK- 1 4 and  the  AN/UYK-20  both  have  floating  pcint 
options. 

In  Table  VI  7-12  we  have  tabulated  the  numter  of 
FORTRAN  or  CMS-2  instructions  (if  the  flowchart  were 
translated  into  FORTRAN  or  CMS-2)  in  the  categories  of 
arithmetic  (AR) , conditional  (IF)  and  control  alteration 
(00)  statements.  In  addition  we  have  given  the  numter  of 
assembly  language  instruction  in  tne  actual  program  anc  the 
number  of  bytes  (8  tits)  the  program  occupies  in  memory. 
The  number  of  CMS-2  statements  would  be  the  same  as  in 
FORTRAN  except  that  each  variable  in  CMS-2  has  to  ts  defined 
in  an  additional  statement. 

Ue  include  the  FORTRAN  and  CMS-2  versiors  for 
purposes  cr  comparison  with  the  assembly  language  program. 
We  draw  soue  conclusions  as  to  relative  efficiencies  of 
programming  at  the  end  of  this  chapter. 

Cne  surprising  fact  is  the  large  number  of 
possible  execution  sequences  which  appear  in  the 
navigaticnal  program,  namely  10*.  The  numter  of  execution 
sequences  is  related  tc  the  number  of  different  functions 
calculated  in  this  program  segment.  As  is  seen  in  Chapter 
V,  the  functional  segments  are  independent  cf  each  other  and 
the  total  number  of  distinct  functions  calculated  ty  the 
navigaticnal  program  is  far  less  than  10«.  Ey  reorganizing 
tue  program,  it  is  also  possible  tc  reduce  the  numter  of 
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:utxcc  st-catnceE. 

AR 

IF 

GO 

TOTAL 

ASSEMBLY 

BYTES 

AIR  DATA I 

19 

9 

6 

34 

118 

242 

AIR  DATA.! 

20 

n 

4. 

1 

23 

87 

168 

AIR  MASS 

ANGLES 

15 

10 

•? 

27 

124 

272 

DOPPLER 

VELOCITY 

16 

5 

4 

25 

90 

176 

SYSTEM 

VELOCITY 

26 

4 

4 

34 

115 

232 

BARO  INRT 

VERT  LOOP 

25 

9 

6 

40 

127 

270 

INERTIAL 

ANGLES 

16 

3 

2 

21 

78 

168 

PLATFORM 

CORRECTIONS1 

17 

2 

21 

100 

200 

PLATFORM 
CORRECTS 2 

28 

1 

1 

30 

243 

488 

TOTALS 

132 

45 

28 

255 

1082 

2216 

TABLE  VI. 7.  A6-E  NAVIGATION 
HIGHER  LEVEL  LANGUAGE  COMPLEXITY 


i 


i ib 


AR 

IF 

GO 

TOTAL 

ASSEMBLY 

BYTES 

COMMAND 

STEERINGl 

33 

4 

4 

41 

109 

242 

COMMAND 

STEERING2 

33 

9 

7 

49 

188 

430 

COMMAND 

STEERING3 

29 

6 

5 

39 

99 

318 

SAMPLE 

INPUTS 

52 

1 

I 

54 

272 

482 

INTERRUPT 

SERVICE 

30 

8 

7 

45 

147 

376 

STEERING 

DISPLAY 

23 

6 

4 

33 

127 

252 

DISCRETE 

OUTPUTS 

4b 

2 

T 

50 

254 

552 

STEERING 

KEY  SELl 

18 

8 

5 

31 

STEERING 

KEY  SEL2 

38 

10 

10 

58 

255 

588 

TOTALS 

301 

54 

45 

400 

1451 

3240 

TABLE  VI.  8.  A6-E  INPUT/OUTPUT 
AND  STEERING  HIGHER  LEVEL 
LANGUAGE  COMPLEXITY 
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AR 

IF 

GO 

TOTAL 

ASSEMBLY 

BYTES 

ROCKET 

ATTACK 1 

26 

5 

3 

34 

113 

252 

ROCKET 

ATTACK2 

16 

2 

3 

21 

100 

216 

BOMB 

ATTACK 1 

13 

3 

3 

19 

62 

136 

BOMB 

ATTACK 2 

38 

9 

2 

49 

240 

480 

BOMB 

ATTACK3 

29 

3 

3 

35 

261 

532 

BOMB 

ATTACK 4 

2 2 

9 

4 

35 

164 

356 

BOMB 

ATTACKS 

15 

9 

7 

31 

73 

168 

BOMB 

ATTACK6 

17 

14 

7 

38 

98 

224 

BOMB 

ATTACK? 

38 

15 

11 

64 

229 

498 

COMMON 

DRAG 

21 

5 

3 

29 

209 

434 

TOTALS 

235 

74 

46 

355 

1549 

3296 

TABLE  VI. 9.  A6 - EB ALL I ST 1 OS  FUNCTION 

HIGHER  LEVEL  LANGUAGE  COMPLEXITY  | 
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AR 


IF 


GO  TOTAL 


ASSEMBLY 


BYTES 


GREAT  CIRC  14  0 

NAVIGATION 


TRACK  RADAR  13  9 

TESTS 


DEPR  ANGLE  10  12 

TRACKING- 1 


TRACK  SCAN  21  9 

TESTS 


DEPR  ANGLE  22  9 

TRACKING- 2 


LINE  OF  SIGHT  26  8 

RANG1 


LINE  OF  SIGHT  19  13 

RANG2 


0 14  82 

7 29  78 

10  32  102 

5 35  157 

9 40  112 

4 38  159 

1 39  107 


164 


174 


250 


338 


268 


322 


244 


SHRIKE 

RANGING 


TOTALS 


232  104  75  411  1321 


2932 


TABLE  VI. 10.  A6-E  TRACKING  AND 
RANGING  FUNCTION  HIGHER 
LEVEL  LANGUAGE  COMPLEXITY 
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AR  IF  GO  TOTAL  ASSEMBLY  BYTES 


TARGET  50  6 5 61  152  306 

INITIALIZE 


TARGET  POS  43  7 5 55  216  490 

FILTERS  1 


TARGET  POS  10  2 1 13  15  36 

FILTERS2 


SLEW  17  5 5 27  50  102 

UPDATE1 


SLEW  46  16  8 70  189  396 

UPDATE2 


ANGLE  27  7 3 37  136  284 

RATES 


CURSOR  38  7 3 48  316  678 

UPDATES 


RADAR  15  4 3 22  86  230 

OUTPUTS 

TARGET  POS  18  1 0 19  88  176 

UPDATES 


TOTALS  264  55  33  352  1248  2698 


TABLE  VI. 11.  A-6E  TARGET  UPDATES 
HIGHER  LEVEL  LANGUAGE  COMPLEXITY 
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RESELECT 

L0GIC4 


14  20  8 42 


RESLECT 

LOGIC5 


10  16  o 32 


ATTACK 
SELECT 1 


29  11  4 44 


ATTACK 
SELECT 2 


28  10  6 44 


STEP  OUT 
OF  ATTACK 


11  19  5 35 


ATTACK 

VALIDl 


ATTACK 

VALID2 


TOTALS 


:02  144  69  415  1218 


TABLE  VI. 12.  Ao-E  ATTACK  DECISIONS 


RESELECT 

LOGIC1 


RESELECT 

LOGIC2 


AR  IF  GO  TOTAL  ASSEMBLY  BYTES 


14  10  5 29 


24  15  12  51 


HIGHER  LEVEL  LANGUAGE  COMPLEXITY 


2.  T^dcki and  Fanning  Calculations 

Ifce  purpose  cf  this  segment  cf  the  program  is  tc 
establish  the  position  ct  the  target  with  respect  tc  the 
airplane.  At  tne  start  ct  a mission  uj  to  four  target 
positions  m a seguential  order  can  be  inserted  into  the 
computer  from  the  keyboard.  Once  the  aircraft  is 
surriciently  close  to  a target  so  that  the  landmarks  which 
appear  cn  the  radar  display  allow  the  bombardier  to  place 
nis  cutset  cc  the  target,  then  the  ranging  and  tracking 
calculations  are  made  in  a local  coordinate  system.  It  is 
necessary  tc  determine  the  velocity  of  a moving  target,  the 
line  along  which  the  aircratt  should  move  sc  that  a released 
bomb  or  rocket  would  hit  the  target.  Tables  VI. 3,  VI. u, 
V 1.5,  aud  VI. o give  the  complexity  measure  tor  these 
calculations . 

3 . ballistics  Calculations 

Ihe  ballistics  calculations  determine  from  the 
initial  conditions  at  release  the  down  range  travel  and  the 
time  or  fall  cf  any  particular  weapon.  from  a mathematical 
point  of  view  this  corresponds  to  solving  a second  erder 
ncn-linear  differential  eguation  with  given  initial 
conditions:  the  initial  position  of  the  aircraft  and  the 
initial  air  velocity  of  the  aircraft.  Ihe  numerical 
procedure  used  in  the  ballistics  algorithm  uses  polynomial 
ap proximatiens  rather  than  an  integration  method  for  solving 
tne  differential  eguations.  Ihis  is  done  to  reduce  the 
execution  time  cf  the  program.  The  ballistic  calculations 
are  described  in  Table  VI. 7 andVl.6.  Table  VI. 9 ancVI.10 
contain  the  attack  decision  making  process.  Arithmetically 
this  process  is  not  demanding.  However,  from  control 
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ccmplexi  ty  point  of  view  this  is  a difficult  process  to 
test.  It  contains  10‘7  execution  sequences. 


4.  Sgflscr  I/O  and  Steering 

Ibis  segment  of  the  program  controls  tlie  analog  to 
digital  converter.  The  conversion  is  interrupt  driven  at 
the  rate  oi  20  times  per  second.  The  data  is  gathered  and 
smoothed  for  processing  at  the  update  rate  cf  5 times  pet 
second.  The  update  rate  of  5 times  per  second  is  used  for 
all  processes  other  than  the  data  gathering  function.  The 
analoq  and  digital  outputs  are  also  generated  ir  this 
program  segment.  The  digital  to  analog  conversion  is  done 
under  the  control  of  the  computer.  Correction  signals  to 
inertial  navigation  unit,  radar  antenna  ccntrol,  display 
control  and  steering  command  are  generated  ty  this  secment. 
Tables  VI.  11  and  VI.  12  contain  the  complexity  parameters. 

i»e  can  express  the  entire  functional  requirements  of 
the  Ab-i  operational  flight  program  by  the  latle  VI.  1J.  The 
headings  are  described  as  follows: 

3-3hcrt  instructions,  1b  bit  integers 

P-!1edium  length  instr  uctions : lead,  store,  and 

compare  tloating  point  quantities 

L-Long  floating  instructions:  FAD,  EMU,  F'DV 

X-5uLprogt ams  which  calculate  sines,  cosines,  etc. 

iNTG-numbor  of  integer  variables  in  the  progtan 


program 


HEAL-number  of  floating  point  variables  ir  * he 
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r 


EXT-nuiaber  or  variables  which  are 

used  by  other  programs 
external  to  the  named  cne. 


Instructions  Variables  External 


S 

M 

L 

X 

Int 

Real 

Int 

Real 

Navigat iona  t 

51 

302 

225 

29 

18 

125 

3 

47 

F'unct  ion 

85 

405 

262 

31 

18 

125 

3 

47 

Tracking  & 

239 

730 

374 

64 

50 

192 

7 

7 

Rang ing 

4 33 

954 

4 39 

71 

50 

192 

7 

7 

na l 1 ist ics 

234 

557 

•120 

28 

20 

170 

19 

16 

Calculat ions 

518 

7 9 3 

467 

29 

20 

170 

13 

16 

Sensor  I/O  & 

2 33 

19R 

98 

11 

87 

103 

17 

16 

Steering 

34  3 

3 30 

132 

14 

87 

10  3 

17 

16 

Table 

VI  , 

.13 

Summary  of 

A6-E 

Program  Segments 


1 r 4 





mi 


■ 


mmmmrni 


” 


wan 


Bow  one  of  each  program  segment  expresses  the  number 
cf  instructions  in  the  most  time  consulting  execution 
sequence,  that  is,  the  worst  case  execution  time.  Row  two 
contains  the  total  number  of  instructions  in  the  four 
categories.  vie  use  these  values  to  estimate  worst  case 
execution  times  and  memory  requirements  fer  progran  and 
data.  From  the  number  of  variables  used  externally  to  the 
subprogram,  we  can  estimate  the  worst  case  time  requirements 
for  data  transfers  on  the  bus. 


We  present  the  Ab-E  in  sufficient  level  of  detail  so 
that  we  can  extrapolate  from  this  data  the  functional 
requirements  for  other  aircraft,  in  particular,  the  VS10L. 
Because  tne  A6-E  is  a functioning  system,  it  dees  represent 
a real  system  rather  than  a hypothetical  one.  If  the 
armaments  and  sensors  of  the  VSTOL  are  functionally  the 
same,  then  we  can  expect  close  similarity  in  the  operational 
flight  program. 

A few  points  about  the  nature  cf  the  Ab-E  program 
might  be  made.  There  is  a large  number  cf  tranch  statements 
in  relation  to  arithmetic  statements.  On  the  average,  one 
third  of  all  statements  are  tranch  (IF)  statements  in  the 
FORTRAN  i nplementation . More  than  half  cr  the  statements 
are  control  statements  (IF,  GO).  This  indicates  that  the 
control  complexity  is  very  high  and  hence  testing  the  system 
is  difficult.  The  ratio  of  FORTRAN  statements  to  bytes  cf 
machine  language  program  is  1 to  8.  'This  is  fairly  typical 
cf  higher  level  languages,  although  scientific  programs 
would  have  mere  code  generated  from  one  FOR T B AN  instruction. 
Another  noted  fact  is  that  the  maximal  time  execution 
sequence  contains  approximately  70%  of  the  instructions  in 
the  entire  program . The  actual  assembly  1 anguage  pregra m 
contains  25*  mere  instructions  than  the  assembly  language 
programs  which  contain  floating  point  operations.  This 
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difference  is  explained  partially  by  noting  that  scaled 
arithmetic  operations  need  a large  number  of  shirt 
operations.  Also  logical  operations  such  as  masking 
operations  were  neglected  in  the  floating  point  version  of 
the  asseotly  language  program. 

5.  Ihe  A 7- E Tactical  system 

The  A7-E  computer  system  is  r ucctional ly  very 
similar  to  the  Ab-E.  Although  the  computer,  the  ASN91 
(IP-2)  is  different,  its  capability  is  nearly  the  same  both 
in  terms  of  maximum  memory  capacity  ( 1 1> K)  and  execution 
speeds.  The  word  size  is  1o  bits,  instead  of  32,  although 
double  precision  operations  exist. 

The  sensors  for  navigation  are  functionally  the 
same,  the  tracking  radar  is  functionally  similar,  tne 
ordnance  and  weaponry  overlaps  to  a large  extent.  The  major 
difference  is  that  one  man  functions  both  as  the  pilct  and 
na vigatcr/tcmtardier . The  display  is  guite  different  in 
appearance,  although  from  the  point  cf  view  cf  an 
operational  computer  program  the  differences  are  minor. 

Ihe  programming  for  the  operational  program  was 
designed  and  carried  out  by  different  people,  herce  a 
different  analysis  and  different  numerical  methods  were  used 
to  solve  the  same  problems.  We  did  not  carry  out  the  same 
analysis  for  the  A7-E  as  we  did  for  the  A6-I  because  cf  the 
lack  cf  resources.  We  would  not  be  surprised  tc  find 
considerable  differences  in  the  number  cf  instructions  to 
carry  out  the  ballistics  function.  Iwo  studies  have  shown 
that  eguivalent  results  are  abtained  by  programs  which  are 
much  shorter  [6],  [14]  and  integrate  the  differential 
equations  directly  rather  than  using  pclyrcmial 
approximations.  The  functional  complexity  is  nevertieless 


1 2o 


similar  in  *erms  of  execution  time 


a.  OVERVIEW  OF  THE  FIGHTER  AIRCRAFT  F-15  ANC  F- 1 B 

Figure  VI. 13.1  deficits  the  F-15  tactical  system's 
organisat ion . A network  consisting  of  the  IHa  API  mission 
processor  surrounded  by  9 microprocessors,  each  dedicated  to 
a particular  suttask.  The  netwcr*  is  connected  together  by 
the  1551  time  multiplexed  data  bus.  The  mission  computer  is 
very  similar  to  the  PI-4  computer  in  architecture.  The  add 
and  multiply  speeds  are  twice  as  fast  and  the  divide  speed 
is  four  times  faster  than  the  PI-4  computer's.  There  is  no 
floating  point  option. 

The  F-lfc  tactical  system  is  shown  in  Figure  VI. E. 2 
lhe  two  mission  computers,  AN/UYK-14's,  are  surrounded  fcy  12 
microprocessors,  each  with  its  own  special  function.  The 
1553  bus  again  is  used  to  interface  the  network. 

A functional  description  cf  the  system  was  net  yet 
available  ioi  this  study.  From  the  Figures  VI. a. 1-2,  it  is 
evident  that  some  of  the  functions  carried  out  ty  the 
mission  computer  in  Ao-E  are  carried  out  by  the  peripheral 
computers:  inertial  navigation,  radar  tracking,  display 

processing,  air  data  and  stores  management.  The  flight 
control  functions  are  carried  out  ty  the  special 
dual-redundant  dedicated  prccessors.  A maintenance  data 
recorder,  a communications  systems  controller  are  new 
features  and  a laser  spot  racker,  forward  locking  infra  red 
(FLIR)  sensor  are  added  sensors  absent  from  the  attack 
aircraft . 
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Fig,  VI.B.l  The  F-15  Avionics 


doth  .the  dual  bus  and  the  dual  nixssicn  computers  are 
there  for  redundancy  and  graceful  degradation.  The  bus 
coitrol  function  is  handled  by  one  or  the  ether  of  the  two 
mission  computers. 


C.  CVEEVIEt.  Of  THE  P3-C  ANE  S3-A  SUSTEMS 


The  function  of  both  aircraft  is  guite  different  from 
the  attack  and  tighter  aircraft.  Ine  PJ-C  is  a land  based 
aircraft  which  is  primarily  used  for  patrol  duty.  It  is  a 
large  aircraft,  can  accommodate  a large  crew  as  well  as  a 
heavy  payload  of  expendable  passive  or  active  sonotouys, 
together  with  ordnance  for  attacking  submarines. 

Its  mission  is  to  navigate  to  its  patrcl  position,  drop 
the  sensors  which  relay  acoustic  signals  tc  the  aircraft  for 
processing,  attack  on  command,  aua  return  to  base.  Its 
advantage  is  that  it  can  stay  on  station  ter  a long  period 
cr  time:  its  disadvantage  is  that  it  is  landbased  and 
relatively  slow. 

The  F3-C  tactical  system  consists  of  a CP901  computer, 
supported  by  a drum  auxiliary  memory.  The  computer  has  a 30 
tit  word  length,  typically  uses  4dK  words  of  memory 
expandable  tc  b5K.  Its  execution  speeds  are  in  the  5-20 
aicrcseccnd  range.  The  drum  expands  its  auxiliary  oemory 
size  to  almost  40GK  words. 

Its  mest  cucrent  software  system,  P3-C  UPDATE  II,  uses 
dual-redundant  inertial  navigational  sensors,  Doppler  radar, 
and  the  Cmega  radio  navigation  system  in  erder  to  determine 
its  geographic  position.  During  the  tactical  phase  of  its 
mission  it  navigates  with  respect  to  the  tuoy  field.  The 
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computer  can  be  used  tc  release  tae  buoys  at  the  rignt 
instant  to  drop  into  a predesignated  position.  Thus  the 
ballistics  function  is  carried  by  the  computer. 

The  signal  processing  details  are  classified  ard  not 
included  in  the  report.  The  stores  management  function  is 
carried  out  by  this  computer  as  well.  Except  for  the  signal 
processing  function,  the  P3-C  carries  out  the  very  same 
functions  as  the  A6-E.  Functionally  this  "cere"  process  is 
very  similar. 

Currently  the  P3-C  system  is  execution  time  tound. 
Eecause  the  entire  program  cannot  reside  in  memory,  pregrams 
must  be  brought  in  from  the  drum,  executed,  data  used  for 
ether  prccessas,  the  program  overlaid  by  another  and  sc  on. 
The  operating  system  must  therefore  be  icie  complex  and  a 
substantial  amount  of  system's  overhead  arises  because  of 
the  limited  memory  size  and  the  overload  on  the  central 
processor . 

The  S 3- A is  very  similar  in  its  functicns  to  the  E3-C. 
Eecause  of  its  smallness,  it  can  land  on  carriers.  The 
snallness,  however,  limits  its  time  on  target,  limits  its 
crew  to  four  and  its  payload.  Eecause  of  its  faster  speed 
and  shipboard  base  it  can  make  up  fer  some  of  the 
disadvantages. 

The  tactical  system  consists  of  a dual  UNIVAC  1832 
processor.  In  its  maximum  ccnf iguration  it  can  have  2S6K  32 
bit  words  of  memory.  The  dual  central  processor 
configuration  is  used  for  both  processing  speed  and  graceful 
degradaticn.  Floating  point  hardware  is  ixplemented  and  in 
its  capability  and  architecture  it  is  identical  tc  the 
AN/UYK-7. 


C.  THE  FUNCTIONAL  RETIREMENTS  OF  THE  VSTCL  TACTICAL 
SYSTEM 


1.  i51£i  fighter-attack  version 


The  functional  requirements  tor  VSTCL  lighter-attack 
version  are  assumed  to  be  similar  to  A-oE,  A7-E,  F15,  Fid. 

The  sen  scrs  are  likely  to  include  the  presently  usee  cnes 
for  navigation  and  target  tracking.  Ihe  major  additions 
will  be  in  the  engine  monitor-ccntrol  and  landing  or  takeeff 
flight  ccntrcl.  There  will  be  unrorseen  new  sensor  and 
effector  development  wich  results  in  a need  for  designing 
growth  capability  into  the  system. 

He  shall  use  the  A6-E  program  actual  data  as  an 
estimate  cf  the  needs  for  these  functions  which  are  similar. 
Table  VI. D.  1 gives  cur  estimate  based  on  the  data  derived 
from  the  A6-E.  This  is  compared  to  an  estimate  given  in  .» 
Naval  Weapons  Center  Report.  Our  estimates  are 

somewhat  lower,  under  the  assumption  that  memory 
requirements  for  programs  and  data  will  not  differ 
substantially  from  present  values  whatever  computer  is  used 
fer  the  implementation. 

The  comparison  to  Naval  Weapon  Center's  estimate 
does  not  include  their  25%  safety  margin,  which  brings  their 
total  estimate  to  1t>3,000  bytes  of  memory. 

Cur  estimate  amounts  to  a little  mere  than  twice  the 
memory  presently  used  in  the  Ah- E . Of  course,  only  time 
will  tell  whose  estimate  is  closer  to  the  value  usee.  Til 
distributed  systems  design  it  is  not 
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Program  Name  Memory  Requirement  Estimates 


A6-E  Program  or 
Estimate 

NWC 

Estimate 

Executive 

7600 

7200 

Navigation 

2716 

9400 

Air  to  Surface 

6620 

7100 

Air  to  Air 

2800 

4600 

Data  Link 

2500 

2260 

Target  Tracking 
Multiple  Targets 

7042 

9000 

Displays  and 

Data  Entry 

10,000 

25,900 

Engine  Management 

10,000 

16,000 

Flight  Control 

8,000 

- 

Unforseen  25% 

10,000 

20 , 365 

Total 

71,598 

101,925 

Table  vi.D.l  Estimates  of  Program  and 
Data  Length  in  Bytes  (8  bits)  for  VSTOL  (Attack  Version) 
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crucial  that  the  estimate  he  correct  tc  the  nearest  memory 
mcduie.  If  acre  processing  is  needed  another  processor  with 
its  own  memory  can  te  added.  In  case  of  a centralized 
computer,  it  is  more  important  to  leave  enough  space  for 
expansion,  because  exceeding  the  availaole  maximum  memory 
size  causes  serious  difficulties  in  systems  design. 

2.  VSTCL  AS  W Version 

Tc  make  an  estimate  cf  *he  runcticral  requirements 
fcr  the  AS*  version  is  somewhat  mere-  difficult.  If  the 
sensors  will  be  similai  to  F3-C  ^nd  S3-A  then  the  major 
differences  will  exist  in  th*  dial  .1  y processing.  He  are 
assuming  that  the  numoer  or  p*t  sonne  11  carried  ly  the 
aircraft  will  be  less  than  or  e^ual  to  the  S3-A. 

He  shall  use  tht  PJ-c  as  a functional  guideline  in 
our  estimate  of  computer  capacity  needed  for  the  ASH  version 
cf  VSTCL.  The  processing  rates  will  also  te  assumed  tc  be 
those  used  for  the  P3-C.  Table  VI. d. 2 contains  the 
infcrmaticn  for  the  program  and  data  space  estimated 
requirements. 

He  have  not  seen  any  program  complexity  estimates 
fcr  ASW  version  of  VSTCL.  Our  estimates  rely  heavily  cn  the 
£ 3-C  and  S3-A  present  implementations.  The  execution  rates 
cf  the  functional  segments  vary  and  some  are  considerably 
lower  fcr  ASH  applications  than  are  fighter  or  attack 
aircraft.  The  operating  systems  in  current  implement  at  ions 
are  more  complicated  because  a large  part  cf  the  operaticnal 
program  resides  an  drum  and  is  brought  into  the  computer's 
memory  cnly  when  priorities  permit.  Therefore,  the  use  of 
the  functional  segments  which  exist  in  the  F3-C  and  S3-A 
systems  and  whicn  are  implementation  dependent  do  net  allcw 
us  to  project  into  the  future  with  the  same  accuracy  as  fcr 
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toe  d ttack/ £ aght *r  versions 


Proqram  Name 

Executive 

Navigation 

Tactical  Control 

Communications 

Tracking  and 
Sensor  Management 

Displays  and 
Data  Entry 

Engine  Management 
Flight  Control 
Signal  Processing 
Unforseen  25% 

Total 


Memory  Requirement  Estimates 

10,000 

7.000 

20,000 

4.000 

9 ,000 

20,000 

10,000 

8.000 

80,000 
41,750 

208,750 


Table  VI. d. 2 Estimates  of  Proqram  and  Data 
Length  in  Bytes  (8  bits)  for  VSTOL  ASW  Version 


VII.  SYSTEM'S  IMPLEMENTATION 


In  this  chapter  we  assume  that  the  applications  programs 
have  been  designed,  decisions  on  which  computers  to  use  have 
been  made  and  the  interconnection  scheme  has  teen 
determined.  We  shall  look  at  alternative  implementations 
from  the  point  of  view  that  the  same  application  pregrams 
must  be  executed  on  the  system  witn  the  same  update 
f reguenc  y and  with  a numeric al  accuracy  which  is  nor 
degraded  by  the  computational  system.  Although  our  study 
concerns  itself  with  the  future  systems  and  therefore  the 
computer  systems  cf  the  early  1980's  would  be  the  ones  used 
tc  implement  the  systems,  we  shall  use  presently  available 
computers  tc  demonstrate  the  feasibility  cf  constructing 
homogeneous  distributed  systems  from  present-day  technology. 
Again,  LSI  computers  of  the  1980's  will  simply  mean  fewer 
chips  in  the  network  compared  tc  present  estimates. 


A.  HOMOGENEOUS  IMPLEMENTATION 


1 • The  Systems  Hardware 

Ihe  system  is  built  from  identical  single  beard 
processors  such  as  the  INTEL  SBC80-2C  or  the  Texas 
Instruments  TM9900.  The  boards  are  connected  by  the  INTEL 
MULTIBUS,  II  TILINE  or  the  Digital  Eguipirect's  UNIBUS.  A 
group  of  single  board  computers  connected  cn  a parallel  bus 
is  called  an  affinity  group  [4],  as  saewn  in  Figure  VII. A. 1. 


Figure  VTT.A.l  Two  Affinity  Groups  of  N Single 
Board  Computers  in  a Homogeneous  Distributed  System 
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Ihysical  remoteness  of  system's  elements  makes  4 
parallel  connection  expensive  and  inconvenient . Therefore, 
the  physically  remote  system's  elements  are  connected  Ly  a 
serial  bus,  such  as  the  MLSTD  1553  A/B  bus,  with  either 
twisted  pair  or  a fiberoptic  connector  as  the  physical 
device  which  provides  the  interface.  The  present  maximum 
data  rates  oil  the  parallel  bus  are  40-50  megabi  ts/seccnd, 
whereas  1 megabit/sec  is  the  present  standard  maximum  rate 
tor  ML8TC  1553.  In  a typical  couf ig urat icn  the  system  has 
dual  serial  tusses  to  provide  redundancy  and  single  parallel 
Lusses  tc  provide  local  service.  The  Texas  Instruments 
study  [4]  refers  to  these  bus  structures  as  global  and  lccal 
tus  structures. 

There  are  a number  of  alternatives  even  with 
homcgenecus  architectures  to  construct  systems.  For 
example,  we  could  use  the  presently  available  chips  and 
presently  available  single  ooard  computers.  We  ccuid 
consider  enhanced  systems  by  adding  presently  available- 
floating  pcint  hardware  to  the  systems.  We  could  also 
consider  scaled  arithmetic  and  floating  point  arithmetic 
with  a sixteen  bit  mantissa. 

In  order  to  keep  the  alternatives  at  a reasenabit 
number,  we  consider  only  the  INTEL  a080E  (the  E stands  for 
an  enhanced  floating  pcint  arithmetic  unit),  the  TI  4400, 
LSI- 11  each  with  a floating  point  unit. 

-•  Ei§i£ifeut^  Systems  resign 


design  is 
and  exit 


Me  assume  that  the  modular  program 
complete  so  that  each  module  has  a single  entry 
pcint,  called  a control  segment  in  Chapter  V.  Tc  each 
control  segment  corresponds  a data  tlcwgraph  which 
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explicitly  identifies  the  input  and  output  data  and  ccntrol 
variables,  lhe  input  variables  must  be  available  tc  the 
process  before  the  execution  starts. 

If  a single  computer  is  used  tc  carry  cut  the 
processes,  as  is  the  case  with  A6-E,  then  each  process  is 
executed  in  a predefined  sequence.  If  a process  is  not 
needed,  its  execution  is  bypassed.  Figure  VII. A. 2 shows 
the  time-line  of  the  processes  for  one  execution  of  the  A6-E 
cperaticnal  flight  program.  The  worst  case  execution 
sequence  is  less  than  .2  seconds  for  the  entire  program. 
There  is  a period  of  idle  time  before  the  next  iteration  is 
carried  cut. 


cf  input 
the  lang 
data  flo 
elsewher 
the  flow 
correspo 
idea  usi 


Each  process  is  a function  which  operates  on  a set 
values  and  generates  a set  of  output  values.  In 
uage  of  Chapter  V the  function  may  be  described  as  a 
wgraph.  The  number  of  output  values  which  are  used 
e in  the  pregram  can  be  identified  as  vertices  of 
grapn  which  connect  the  data  flcwgraphs  of  the 
nding  processes.  Figure  VII. A3  illustrates  the 
ng  hypothetical  data  flowgraphs. 
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Figure  VII. A. 2 Time  Line  for  the  Single  Computer 
A6-E  Execution  Sequence 


Figure  VII. A. 1 Data  Flowgraphs  for  Three 
Hypothetical  Processes 
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Ibe  s aie  computational  process  can  te  carried  cut  ny 
a collection  ct  slower  processors.  As  an  example,  let  us 
pretend  that  the  processors  we  wish  to  use  are  approxinately 
three  times  slower  than  the  single  prccessor  which 
successiully  is  able  to  carry  out  the  three  processes.  It 
computers  1 ,2,  and  3 are  assigned  to  processes  1,2,  ard  3, 
then  their  execution  times  become  three  times  longer,  as 
shown  in  Eigtre 


< 

Computer  1 

l 

Computer  2 

l 

Computer  3 

t— — 

Fiqure  VII.  4 Time  Lines  tor  a Three 
Computer  Implementation  of  the  Distributed  System 

V II A . 4 Each  computer  is  able  to  complete  its  process  in 

the  .2  second  interval.  If  the  processes  are  completely 
independent,  then  the  i-th  iteration  can  be  carried  out 
simultaneously  and  no  difference  would  be  observable  between 
the  single  computer  solution  or  the  three  computer  solution. 
If  the  processes  use  each  other's  results  as  indicated  in 
Eigure  VIIA.2.2.,  then  the  iteration  rate  wculd  reraair.  less 
than  .2  second  but  the  dependent  values  would  be  delayed  by 
three  iterations.  It  is  therefore  important  that  the 
partitioning  process  identify  the  time  critical  data 
flowgrapns  and  place  them  into  the  either  the  same  computer 
or  the  same  iteration  interval. 
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Another  aspect  which  becomes  iapartar.t  is  the 
transfer  of  data  between  computers.  I’he  parallel  data  bus 
allows  several  terms  or  data  transter  at  high  transfer 
rates.  'Ihe  use  of  common  memory  for  these  data  values  which 
need  tc  be  transferred  between  computers  is  particularly 
efficient  whenever  relatively  few  such  values  are  tc  be 
placed  cn  the  system  bus.  Computers  would  interfere  with 
each  other  cnly  when  two  computers  simultaneously  wish  to 
access  the  common  memory. 

Other  methods  of  message  transfer,  which  require 
simultaneous  attention  from  the  transmitting  and  receiving 
computers,  would  give  rise  tc  more  message  transfer 
overhead.  However,  the  maximum  data  transter  rates  cf  40-50 
megabits  per  second  on  the  system  uus  make  the  data  transfer 
overhead  almost  negligible  as  seen  treui  the  calculations 
which  f o 1 lc w . 

ic  establish  that  such  a system  ct  single  board 
computers  can  successfully  sclve  the  tactical  protlen,  we 
first  lock  at  the  Ao- K program,  which  is  analysed  in 
complete  detail,  and  the  summary  information  is  given  in 
'Ialle  V . 1 . Ihe  worst  case  execution  time  estimates  to  carry 
cut  each  cf  the  processes  at  the  rate  of  five  repetitions 
per  second  is  tabulated. 

If  we  chose  to  carry  out  the  Ao-fc  process  using 
three  ccmputers,  one  choice  is  to  assign  the  navigational 
function  tc  one  computer,  ballistic  calcul a t ions, 
input/output,  aud  steering  calculations  to  another,  tracking 
and  ranging,  and  sensor  calculations  to  a third.  This 
assignment  would  tend  tc  minimize  the  bus  traffic  because 
the  number  of  data  items  to  be  transferred  froa  the 
navigational  computer  is  47  floating  point  quantities  and  J 
logical  variables.  The  ballistics  computer  would  need  to 
communicate  1o  floating  point  and  1H  logical  variables.  The 


tracking,  ranging,  sensor,  input/out put , and  steering 
computer  will  need  to  communicate  24  floating  point  and  23 
logical  variables.  Since  these  variables  are  communicated  5 
times  pet  second,  the  total  number  or  bits  per  second  is 

(44  ♦ 87  * 4)  * 8 * 5 = 15,680 


1 

; 


If  the  communication  takes  place  at  the  maximum  rate 
of  40,000,000  bits  per  second,  the  total  data  communications 
time  is  .39  milliseconds  every  second.  Added  to  this  wculd 
be  the  tine  required  tc  service  and  set  up  two  interrupts 
from  each  of  three  computers  five  times  per  second,  which  as 
a maximum  cf  30  interrupt  services  per  second.  Interrupt 
service  times  are  at  worst  about  50  microseconds  per 
interrupt.  This  would  add  1.5  milliseconds  to  the  data 
transfer  tines.  If  the  common  memory  concept  is  used  for 
data  transfers  then  each  memory  access  requires  an 
additional  system  bus  access  cycle  of  200-300  nanoseconds, 
which  would  add  a total  of 

(44  ♦ 87  * 4)  * 5 * 2 / 5 = 784 

to  the  execution  time  every  second.  Therefore,  a three 
computer  system  would  in  the  worst  case  use  .15*  of  the  bus 
capacity.  The  total  estimated  execution  times  in  seconds 
fer  each  computer  including  communication  time  is  listed  in 


Tanle  VII.  A. 5. 

8080  E 

LSI-11 

TI  9900 

Computer  1 .2786 

Navigation 

.2685 

.267 

Computer  2 .3916 

Ballistics  & I/o 

. 370 

. 368 

Computer  3 .683 

Track  & Range 

.660 

.658 

Table  VII. A. 1 Total  Estimated  Worst  Case  Execution  I 

Times  (Per  Second)  for  the  A6-E  System 
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V 


Apol ication  Functional  Data  Operating 


Program 

Subprograms 

Unique 

Dup  1 

System 

Total 

Computer  1 

Navigation 

2.2 

K 

1 

K 

.6  K 

.2 

K 

2 K 

6 K 

Computer  2 

Ballistics  I/O 

6.6 

K 

t 

K 

.9  K 

. 1 

K 

2 K 

10. 6K 

Computer  3 

Track  & Range 

9.5 

K 

1 

K 

1.2  K 

. 1 

2 K 

12. 8K 

Totals 

17.3 

K 

3 

K 

2.7  K 

.4 

K 

6 K 

29. 4K 

Table  VII. 2 Amount  o*7  Memory  Required  (Bytes) 

For  the  Distributed  System 

Computer  3 is  used  most  heavily  at  about  tb-68% 
capacity.  The  difference  between  the  performance  estimates 
of  the  three  LSI  computers  is  almost  negligible.  This  is 
due  to  tne  fact  that  the  most  time  consuming  operations  are 
the  floating  point  operations.  The  floating  point  unit 
performance  is  nearly  the  same  for  all  three  computers. 

Distributed  systems'  implementation  using  private  memory 
requires  that  certain  programs  exist  in  each  computer 
namely,  the  programs  reguired  for  data  transfers,  the 
functional  subprograms  (SI,  CO,  CN,  AT,  SQ) , and  some 
input-output  handlers.  If  the  systems  use  private  memcry, 
then  the  data  items  shared  by  the  compucers  will  be  copied 
from  one  memory  tc  another  and  in  the  wcrst  case  three 
copies  of  the  shared  data  will  occur. 

The  estimated  number  cf  bytes  of  memory  required  for 
the  programs  is  assumed  to  be  nearly  the  same  in  all  three 
LSI  computers.  Me  estimate  the  program  length  in  the  PI-4 
computer  to  be  nearly  the  same  as  in  the  LSI  computers 
because  cf  the  similarity  in  architectures.  The  estimated 
memory  reguitemens  for  the  distributed  system  is  given  in 
Iable  VII-J.  We  have  tabulated  in  Table  VII. 3 a • 
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three  computer  arcnitecture  in  which  memory  is  only  shared 
for  common  data  values.  Consequently,  functional 
subroutines,  some  data  and  the  operating  systems  are 
duplicated  in  each  computer.  This  architecture  has  the 
drawback  cf  requiring  more  memory  than  the  corresponding 
single  computer  system.  The  advantages  are  that  single 
beard  computers  which  are  slower  but  much  less  ccstly, 
smaller  in  size,  weight,  and  power  requirements,  can  be  used 
tc  implement  systems  which  require  more  computational 
capability  than  provided  by  cne  single  board  computer. 

Erojections  of  the  future  indicate  that  the 
capability  provided  by  the  prsent-day  single  beard  LSI 
computers  will  be  available  cn  the  single  chip  by  1985.  The 
present  computational  requirements  for  the  A6-E  will 
therefore  be  satisfied  by  a single  board  cn  which  three 
single  chip'  computers  provide  the  computational  capability 
and  the  remaining  chips  are  used  to  interface  the  system  to 
sensors  and  displays.  The  cost,  weight  and  power 
reguiremens  cf  such  a system  will  be  a small  fracticrs  of 
their  present  values.  We  are  net  naive  tc  believe  that  the 
computational  reguiremens  will  remain  fixed.  We  expect  that 
increased  capability  of  the  chips  will  encourage  an  increase 
in  computational  requirements.  We  believe  that  the  most 
cost-effective  solution  to  these  problems  is  a distributed 
system  of  these  chips  which  are  most  widely  used  and  hence 
sell  at  a cost  closest  to  the  recurring  production  costs 
which  are  measured  in  dollars  per  chip. 

3.  The  Distributed  Homogeneous  Systems  Implementation 
Si  VjjTOL 
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»e  wish  to  estimate  the  number  ct  single  beard 
computers  needed  to  implement  the  VSTOL  systems  using 
presently  available  LSI  computers.  Because  the  VSTOL 
aircraft  will  be  comparable  in  performance  tc  the  S3-*  and 
P3-C,  the  present  iteration  rates  for  the  processes  are 
assumed  to  be  sufficient.  Because  the  presently  used 
computers  are  in  the  best  case  ten  times  faster  than  the 
currently  available  LSI  single  board  computers,  certairly  no 
more  than  ten  computers  are  necessary  to  give  the  same 
iteration  rate  as  the  present  systems.  Therefore,  the  tasic 
issue  in  trying  tc  estimate  how  many  single  board  computers 
are  needed  becomes  the  question  cf  memory  size. 

At  this  time  the  single  beard  computer  which 
contains  the  most  memory  has  8K  bytes  of  pregram  memory  and 
2K  bytes  of  RAd.  six  months  frem  now  beth  cf  these  numbers 
will  almost  certainly  double  because  1oK  bit  chips  are 
already  cn  the  market.  Therefore,  with  present  technology 
10  single  rcard  computers  connected  by  a parallel  bus  intc  a 
system  which  contains  a commcn  memory  for  the  variables 
needed  tc  be  shared  is  an  upper  bound  estimate.  This  wculd 
allow  us  tc  build  a system  with  a total  cf  116K  bytes  of 
memory  which  is  well  above  the  estimated  102K  bytes  stated 
as  an  estimated  reguirement  by  Naval  Weapons  Center  [2C]  fer 
VSTOL  attack  version. 

It  is  superfluous  to  state  that  within  a year  the 
system's  memory  size  could  be  200K  bytes  and  as  cur 
estimates  indicate,  this  system  in  19bs  will  be  composed  of 
10  cnips  on  a board  instead  of  10  boards  in  a card  cage. 

4.  jc r t wu ce  issues  of  Distributed  Systems 


In  the  previous  segment  we  have  outlined  a method  to 
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use  existiug  single  board  LSI  computers  to  construct  a 
system  which  solves  a tactical  problem  ot  the  complexity 
which  occurs  on  the  Ab-E.  In  order  to  bring  such  systems 
into  existence,  a program  must  be  generated.  In  most 
airborne  applications,  the  program  development,  testing  and 
maintenance  costs  have  been  Faid  for  each  new  airplane, 
lypically,  the  major  airframe  contractor  assumes  the 
responsibility  tor  the  computer  program.  Closely  related 
functional  aircraft,  (A-oE  A-7S) , (PJ-C,  S3  A ) , have  different 
computers  connected  to  similar  sensors,  displays  and 
weapons.  In  the  past,  programs  were  written  in  assembly 
language  to  maice  program  sice  small  and  execution  tine  as 
short  as  possible.  The  programming  effort  was  repeated  for 
each  new  project.  The  human-intensive  programming  effort 
has  teen  expensive  in  the  past  and  is  continuing  at  the  same 
level.  Tne  decreasing  hardware  costs  encourage  greater  use 
of  computers,  hence  more  programming  of  nearly  the  some  cost 
per  instruction.  Therefore,  not  surprisingly,  the  software 
cost  tc  hardware  cost  ratio  is  approaching  fc0/20  and  likely 
to  coutinue  its  growth. 

Ecth  users  of  computers  and  computer  manufacturers 
recognized  early  that  it  is  tc  bcth  of  their  advantage  to 
make  the  lifetime  of  programs  as  long  as  possible.  The 
development  cr  higher  level  languages  (E0R1KAN,  C0B01,  AIGOL 
etc.)  net  only  increased  the  productivity  ct  progranmers, 
but  also  allowed  the  piograms  tc  be  transferred  tren  one 
computer  to  another,  from  one  generation  tc  another.  When 
disk  systems  replaced  tape  oriented  systems,  many  cf  the 
programs  did  not  survive  intact.  They  had  tc  be 
substantially  rewritten  in  order  to  make  efficient  use  ot 
the  system. 

In  airborne  applications,  the  computet  systems  have 
always  teen  operating  near  their  capacities  both  in  speed 
anu  memory  size.  The  peripherals:  the  sensors,  displays 
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and  effectors  have  not  teen  interfaced  to  the  computers  with 
standard  interfaces.  therefore,  mucn  cf  the  program  will 
have  tc  change,  whenever  changes  are  made  ir  the 
peripherals.  Furt hermcre,  the  real  time  tactical  systems 
are  characterized  by  program  control  complexity  which  is 
much  greater  than  programs  of  similar  size  in  ether 
applications.  Therefore,  the  testing  of  programs  beccmes  a 
lengthy  and  complex  task  which  is  subject  tc  change  whenever 
the  peripherals  change.  The  combined  effect  of  all  the 
causes  is  that  not  much  etrective  transfer  cr  programming 
effort  has  taken  place  from  one  project  tc  another.  Orly  in 
systems  updates,  such  as  P3-C  Update  II,  has  there  been 
suDstantial  saving  of  reprogram aing  effort, 

Iha  present  Navy  policy  is  to  try  to  enforce  the  use 
cf  both  the  standard  higher  level  languages:  CMS- 2,  SC  1-1 
as  well  as  standard  computers.  It  is  hoped  that  enforcing 
these  standards  will  make  the  lifetime  of  tactical  pregrams 
longer  than  cne  generation,  as  well  as  allow  transfers  of 
programs  between  projects.  The  use  or  standard  airterne 
computers,  namely  the  AN/UYK-20  compatible  AN/UYK-14  is 
helpful  in  both  hardware  maintenance  and  ability  tc  use 
program  development  tools,  such  as  compilers,  assemblers, 
etc.  which  have  been  already  developed  for  the  AN/UYK-20. 

This  policy  on  the  surface  appears  to  enable  the 
saving  of  the  large  investment  in  the  stockpile  of  conputer 
programs  which  the  Navy  has  generated  fer  its  tactical 
systems.  Examination  shows  that  this  policy  alone  is  not 
sufficient  tc  allow  tactical  programs  tc  be  carried  frea  on 
generaticn  tc  tne  other.  whenever  the  systems  architecture 
changes,  cr  changes  in  the  sensors  or  displays  occur,  only  a 
minor  pertien  of  the  programming  effort  would  carry  over  to 
the  new  system.  For  example,  the  introduction  of  the  phased 
array  radar  into  a system,  would  not  only  change  the  sensory 
interface  tut  the  entire  tactical  system  because  radically  | 
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new  information  with  different  accuracies  and  different 
information  transfer  rates  becomes  availaole.  Our  choice  is 
tc  either  deny  the  benefits  of  tms  new  sensor  and  pretend 
that  it  is  a traditional  search  radar  in  order  to  preserve 
cur  sortware,  or  rewrite  the  majority  cf  the  program.  When 
disks  replaced  tapes,  there  were  many  attempts  to  preserve 
the  tape  program  by  thinking  of  disks  as  tapes.  These 
temporary  fires  have  leng  since  been  phazed  cut  and  the 
programs  have  not  survived  the  change  in  generations. 

The  Navy  fleet  in  mothballs  in  tne  various  harbors 
is  another  example  of  an  attempt  to  preserve  something  which 
was  extremely  expensive  to  build  and  ouy  and  therefore  to 
throw  it  away  seems  such  a waste.  The  changes  which  have 
occurred  in  snipbuilding  are  happening  at  a much  faster  rate 
in  the  electronics  industry.  Therefore,  attempts  to 
preserve  expensive  applications  software  trett  one  generation 
cf  tactical  systems  to  another  is  net  realistic  with  our 
present  state  of  knowledge  and  ability  tc  predict  future 
changes. 

Successful  preservation  of  software  from  one 
generation  cf  computers  to  another  has  been  accomplished  in 
these  applications  which  are  processor  configuration 
independent.  5y  expressing  the  program  in  a higher  level 
language  such  as  FORTRAN,  it  becomes  useaole  cn  any  computer 
which  has  a FORTRAN  compiler.  The  FORTRAN  compiler  itself 
can  be  made  more  easily  transferable  from  one  generation  to 
another  if  the  so-called  "intermediate  code"  emitted  ty  the 
ccmpiler  is  general  enough  sc  that  the  only  change  necessary 
tc  adapt  the  compiler  to  a new  computer  is  the  rewriting  of 
the  final  phase  of  the  compiler,  namely  the  "code  emitter". 
The  scientific  subroutine  packages,  compilers,  assemblers, 
editors,  and  ether  programs  which  only  depend  on  general 
purpose  input-output  devices  are  examples  cf  programs  which 
have  been  successfully  preserved  rrom  generaticr  to 
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generation. 

lfce  present  Navy  policy  to  force  the  contractors  to 
use  the  "Navy  standard  airberne"  computer  AN/UYK-14  has  the 
following  consequences 

1)  It  creates  a narrow  branch  cf  "Navy  standard 
airborne"  computers  and  thus  prevents  the  Navy's 
participation  in  the  "LSI  revolution"  cf  radical  cost 
reductions  in  hardware  and  software  by  the  use  of  defacto 
"industry  standards,"  the  DEC'S  LSI-11,  INIEI's  8080E,  TI's 
IMS9900 . 


2)  It  tends  to  create  heterogeneous  systems 
consisting  cf  the  "Navy  standard  AN/UYK-14's"  surrounded  oy 
a variety  cf  different  "industry  standard"  microprocessors. 
The  F- 18  and  F-15  designs  are  geed  examples. 

3)  It  will  net  solve  the  problem  cf  preserving  tne 
applications  software  from  one  generation  to  the  next  for 
the  reasons  mentioned  in  the  previous  pages. 

4)  It  will  allow  the  CFS-2M  compiler  to  generate 
code  for  the  AM/UYK-14  and  thus  the  expense  cf  rewriting  the 
compiler  would  be  saved. 

At  tnis  time  we  cannot  cite  successful  single  beard 
distributed  systems  designs.  Much  of  this  design  work  is 
presently  going  cn  and  reports  are  yet  to  he  written.  From 
cur  own  experience,  the  design  and  static  testing  of 
applications  modules  is  the  most  time  consuming  effort. 
Very  accurate  predictions  of  maximum  execution  times  can  be 
obtained  by  writing  and  executing  the  programs  on  existing 
developmental  systems.  Most  cf  program  development  can  be 
accomplished  conveniently  on  systems  which  are  specifically 
designed  for  program  development.  Existing  timesharing 
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systems  which  have  editors,  compilers,  simulators  and 
deouggers  can  be  very  successrully  used  to  develop,  test  and 


debug  the  application  programs, 


Ihe  decisions  cf  which  particular  system  is  tne 
target  iiplementation  hardware  can  be  delayed  until 
virtually  the  last  minute.  Decisions  or  hew  to  "package" 
the  modules  into  single  board  computers  can  be  made  at  any 
time  when  sufficient  performance  data  ror  both  the  computer 
and  the  interconnecting  bus  is  availaule.  Analysis  software 
which  determines  execution  times  and  data  transfer 
requirements  directly  from  the  programs  is  a useful  tool 
which  would  make  the  task  of  assigning  modules  to  computers 
easier. 

•Ihe  dynamic  testing  of  the  modules  which  beicnc  to  a 
single  beard  computer  can  then  be  done  with  using  in  circuit 
emulation  systems.  (INTEL’S  in  circuit  emulator,  ICE,  is 
one  example  or  such  systems  provided  by  the  manufacturer  to 
permit  the  monitoring  and  final  debugging  of  a system  which 
directly  interfaces  with  peripheral  circuits.)  Each 
computer  can  be  tested  independently  to  check  whether  cr  not 
the  predicted  performance  corresponds  tc  the  "in  circuit" 
performance. 

Scttware  tcols  to  monitor  the  interaction  of  several 
computers  on  a data  bus  are  presently  under  development  by 
the  iistcibuted  LSI  computer  manuract urers . These  software 
tools  at  tne  final  integration  tests  are  useful  to  resolve 
interaction  difficulties. 

lu  summary,  the  software  development,  testing, 
debugging  and  maintenance  is  basically  no  different  for 
distributed  systems  than  it  is  for  single  ccaputer  systems. 
Only  in  the  final  integration  phase,  the  monitoring  and 
debugging  offers  some  new  aspects.  A wav  cf  monitoring  and 
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recording  t oe  in  forma  ti  on  on  the  uus  would  be  to  dedicate 
cue  single  beard  computer  to  be  the  monitor-recorder.  Our 
recommendation  is  to  use  high  level  languages  which  are  not 
cnly  standard  in  the  Navy  but  extend  to  at  least  the  Defense 
Department,  preferably  boyond.  Use  or  detacto  standards, 
namely  languages  which  have  become  standard  because  or  hign 
degree  of  use  are  preferable  to  decreed  standards.  Our 
recommendation  is  to  phase  out  CMS-2  because  it  no  longei 
efters  signiricant  advantages  over  defacto  standards  such  as 
FORTRAN.  With  the  use  of  floating  point  arithmetic,  the 
scaled  arithmetic  which  CMS-2  supports  is  nc  longer  needed. 
Ihe  language  BASIC  appears  to  be  becoming  the  defacto 
standard  in  the  LSI  computer  applications.  Ihe  LSI 
environment  encourages  simple,  small  languages  which  are 
easy  tc  learn  and  require  a small  memory  for 
comp  1 let/ in t • r prefer  execution.  Because  distributing  the 
computing  removes  critical  execution  time  problems  and  the 
inexpensiveness  of  memory  removes  the  necessity  tor  being 
parsimonious  with  memory,  higher  level  languages  are 
certainly  appropriate  tor  airborne  computing.  The  cnly 
serious  drawback  of  BASIC  is  that  it  dees  not  support 
"structured  programming  form."  The  language  PASCAL,  ELM, 
and  seme  ether  "structured  languages"  may  eventually  win  the 
popularity  race  for  LSI  computing. 


t.  iitlEHCdtNEUUS  IMPLFMENTAHON 


The  heterogeneous  implementation  is  patterned  after  the 
P-lti  system's  concept.  A dual  "mission"  processor  is  used 
to  increase  system  reliability,  supported  by  a myriad  of 
smaller  processors  each  possibly  ot  different  arithmetic 
capability.  Figure  VI. B. 2 describes  the  implementation 
using  that  alternative. 
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The  main  difference  between  the  hurcjeneous  and  the 
heterogeneous  system  is  that,  the  homogeneous  cne  consists  of 
iJiBtical  LSI  computers  which  ccnmunicate  on  a parallel  tus, 
if  the  computers  are  physically  close  and  cn  a serial  tus, 
if  the  units  are  physically  remote.  The  heterogeneous 
system  may  ccutain  two  or  more  difterent  types  ot  computers 
ccnnected  cn  a serial  bus.  The  same  type  ct  computers  may 
te  connected  on  a parallel  bus,  as  is  the  case  of  tne 
dual-processcr  F-18  system  where  some  memciy  nay  be  shared 
ty  the  two  AN/UYK-14's. 


Thete  is  one  major  reason  ror  heterogeneous  systems, 
namely  tne  feeling  that  the  capability  ot  " a icrocomp i ters" 
is  not  sufficient  tc  carry  cut  the  calculations  required  ot 
an  airborne  tactical  system.  The  dual  systea  ir.  the  F-18 
design  is  justifiable  trom  the  pcint  of  view  cf  reliability. 
It  one  systea  malfunctions,  the  ether  continues  to  operate 
the  system  in  a degraded  mode.  The  sc-called  "mission 
computers"  are  ir.  the  "mi  niccmpu  ter"  class  and  may  (in  case 
cf  AN/UYK-14)  or  may  not  (in  case  or  F—  1 5 ) be  constructed 
from  LSI  chips. 

Ihere  is  a strong  pull  towards  this  form  of  systems 
architecture.  The  subcontractors  who  provide  the  sensors 
have  experience  and  knowledge  or  one  micrccomp'Uter  system 
which  is  used  to  make  their  sensor  "smart."  Different 
subcontractors  would  naturally  be  attracted  to  different 
a ictccomp  ute  is . Use  ot  a "standard"  micrccomp’uter  would 
cause  redesign  and  a higher  price.  The  contractor  at  this 
point  has  no  experience  with  homogeneous  distributed 
systems.  There  is  considerable  risk  from  his  point  ot  view 
especially  if  the  time  pressure  ot  the  contract  requires 
immediate  action.  Therefore,  the  contractors  choice  is  a 
minicomputer,  much  like  the  cnes  he  has  used  in  previous 
contracts.  It  the  program  has  to  be  aocumented  in  CHS-*, 
the  "mission"  computer  must  already  have  a ens-2  compiler. 


Hence,  even  if  a contractor  would  te  able  to  generate  a 
homogeneous  distributed  system  of  LSI  computers  as  the  least 
cost  solution,  someone  would  have  to  provide  a CMS-2 
compiler,  wnich  by  itself  would  cost  an  estimated  $4.9 
million  to  develop  [3].  He  has  no  choice  other  than  the 
heterogeneous  system. 

Minimization  of  aguisition  costs  tends  to  create  a 
heterogeneous  system.  As  noted  earlier,  the  subccntractcis 
who  are  net  using  the  Navy  "standard"  microcomputer  would 
have  to  redesign  their  systems.  This  would  result  in  higher 
aguisiticn  costs. 

Ihe  major  penalty  cf  heterogeneous  systems  for  the  Navy 
ccuies  alter  the  system  has  been  aguired.  Ihe  documentation 
af  several  different  microcomputers,  together  with  different 
assembly  languages,  cr  special  microcomputer  higher  level 
languages  will  cause  educational  problems  for  the 
personnell.  The  cost  will  te  proportional  tc  the  number  of 
distinct  microcomputer  systems  present. 

Spare  parts  which  allow  cn  line  system's  servicing  will 
grow  in  number  in  proportion  to  the  number  af  distinct  types 
cf  computers. 

Me  will  note  that  ir  the  system  is  errerfree  and  if  the 
mean  time  between  failures  reaches  100,000  hours,  as 
discussed  ir  the  next  segment,  then  the  maintenance 
penalties  fer  the  heterogeneous  systems  are  in  total  value 
small  compared  to  the  total  life  cycle  cost  cf  the  system. 
Cnly  experience  will  demonstrate  this. 


C.  COMMUNICATIONS  PROTOCOLS 
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The  communications  protocols  are  dependent  on  the  bus 
structure.  Typicaliy  the  protocol  is  stratified  to  several 
levels.  At  level  zero  is  the  hardware  protocol  which  is 
usually  different  for  different  manufacturers.  There  are 
seme  standards  which  are  of  importance  (IEEE  44d,CAMAC) 

At  level  1 is  software  support  provided  by  the  manufacturer 
so  that  the  user  does  not  need  to  concern  hrmselt  with 
developing  software.  Typically  the  manufacturer  also 
provides  subroutines  at  level  2 which  enable  the  user  to 
carry  out  data  set  transfers,  process  synchronization  etc. 
At  level  J are  usually  higher  level  language  subroutines 
written  in  FORTRAN,  bASIC,  FuSCAL,  etc.,  which  permit  the 
applications  programmer  to  make  higher  level  language 
statements  which  cause  data  transrers  to  target  subsysttras. 
The  applications  programmer  does  not  need  tc  know  any  more 
detail  than  hew  to  use  the  subroutine.  There  are  attempts 
tc  standardize  the  protocols  even  at  this  level.  At  level 
four  are  the  global  operating  systems  (if  any).  For 
heterogeneous  systems  such  developments  would  depend  on  the 
system's  configuration,  which  computers  are  used  ard  how 
they  art  configured.  For  a homogeneous  system,  suen 
operating  systems  are  provided  by  the  systems's 
manufacturer.  (INTEL'S  RMX  80  Real  Time  Executive  system.) 

The  system's  manufacturer  provides  the  baseline  or  a 
kernel  or  such  an  executive.  The  user  builds  a customized 
level  of  software  on  top  of  the  kernel.  In  present  tactical 
systems,  the  development  costs  of  executive  systems  for 
tactical  applications  has  been  entirely  paid  be  the  Navy, 
hidely  usei  LEI  homogeneous  systems  executives  aquisition 
costs  will  be  measured  in  thousands  of  dollars  rathei  than 
millions  ct  dollars  used  to  develop  operating  systems. 


VIII.  CC«f  Aj?liON  OF  ili  I A bi  L1_J  Y Of  IFF  DESIGNS 


A.  MOST  LIKELY  ERRORS  AND  fACLTS 

The  experience  with  LSI  chips  dates  tack  only  a few 
years  and  therefore  statistical  data  about  reliability  as  a 
function  of  time  is  not  yet  complete.  Accelerated  life 
testing  data  is  available  only  on  scmt  systems.  The 
commercial  version  of  the  INTEL  single  beard  computer  S3C 
ti0/10  has  undergone  reliability  analysis.  lhe  accelerated 
lire  test  reported  in  [11]  gives  the  mean  time  between 
failures  (MTEF)  as  91,719  hours  at  90i  confidence.  If  the 
eguipment  is  operated  24  hours  per  day  at  25°C  then  the 
expected  life  of  the  system  is  10  years.  Ttis  corresponds 
closely  to  field  data,  which  indicates  an  MTI3F  of  90,845 
ncurs.  Operating  the  system  at  higher  temperatures,  55°C, 
reduces  the  MTBF  to  an  extrapolated  25, COO  hours.  The 
single  toard  computers  which  are  made  up  of  military 
standard  components  have  net  oeen  studied.  Higher 
reliability  would  be  expected  fer  these  computers. 

In  airborne  systems,  the  sensors,  radio  communications 
eguipment,  displays  and  other  peripherals,  and  power 
supplies  ate  currently  the  least  reliable  systems 
components.  A reliability  improvement  in  the  computer  part 
of  systea  ty  an  erder  of  magnitude  will  exaggerate  this 
problem.  Therefore,  reliability  improvements  to  the  tctal 
system  are  net  likely  to  arise  noticeably  by  increasing  the 
reliability  of  the  computer  portion,  although  distributed 
computer  aichitecture  will  give  the  systems  designer 
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opportunities  to  do  this.  The  observed  mean  time  betweeu 
failure  cf  all  sensory  instruments  and  displays  tor  the  F-4E 
was  48.7  hours  (UEDPS,  6t>- 1 Field  Data)  Page  64,  [9]. 
Therefore,  a system  using  LSI  technology  will  fail  so 
inrrequently  in  comparison  to  the  peripheral  instruments 
that  the  well  known  Maytag  television  commercial,  in  which 
the  serviceman  complains  because  he  has  no  trouble  calls, 
will  indeed  te  the  case. 

E.  TESTABILITY 


Testing  tor  malfunctions  in  a single  computer  system  is 
done  initially  before  takeoff.  Thereafter,  if  the  computer 
fails  in  flight,  the  operator  may  again  invoke  the  test 
routines.  Typically  the  computer  is  too  busy  to  do 
selfchecking . 

In  a distributed  system  the  time  pressure  is  net  as 
great  and  selfchecking  can  be  incorporated  into  the  periodic 
execution  sequence.  In  a system  which  is  homogeneous,  only 
one  test  program  needs  to  be  written.  la  a heterogeneous 
system  each  distinct  processor  needs  its  own  test  program. 
In  a distributed  system  external  checking  may  be 
accomplished.  In  order  for  a computer  to  do  self check ing, 
it  needs  to  te  functioning  to  some  degree.  An  external 
computer  can  te  effective  in  testing  after  selftesting  is  no 
longer  feasible.  Again  homogeneous  systems  have  an 
advantage  over  ueter egenoeous  systems.  Distributed  systems 
have  an  advantage  over  single  computer  systeas. 


C.  DIAGNOSIS  OF  ERKCFS 
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A single  computer  system  is  usually  under  such 


timepressure  that  it  can  afford  to  do  very  little  in 
diagnosing  errors.  Cniy  minimal  error  diagnostics  are 
typically  implemented  in  such  systems.  In  a distributed 
system,  the  timepressure  is  less  critical,  hence  mere 
sophisticat ed  error  diagnosis  can  be  done.  We  generally 
wish  to  protect  ourselves  against  the  most  likely  sources  of 
errors,  namely  the  sensors.  If  independent  measurements 
using  different  instruments  agree  with  each  other,  we 
usually  can  trust  the  results.  If  there  is  disagreement, 
tnen  we  iock  for  inconsistencies,  large  changes  in  small 
time  intervals,  etc.  Small  biases  in  instruments  are 
particularly  difficult  to  diagnose.  However,  with  digital 
systems,  ealitratien  problems  are  easier  tc  sclve  because  it 
is  pcssitle  to  record  information  over  time  periods  anc  make 
small  adjustments.  For  example,  ir  a digital  watch  is  off 
cne  second  a day  consistently,  then  if  we  have  access  tc  the 
count  which  determines  the  displayed  unit  c £ time  we  can 
alter  that  and  correct  the  bias.  Distributed  systems  have  a 
advantage  and  homogeneous  distributed  systems  have  a added 

advantage  because  of  uniformity. 

« 

D.  ERROR  TOLERANT  FUNCTIONING  CURING  MISSIONS 

The  present  systems  implementations  have  already  a large 
degree  or  errer  tolerance.  In  the  A6-E  and  A7-E  the 
navigational  instruments  can  gradually  fail.  There  are 
typically  tcur  modes  of  navigation:  inertial- Cop  pier, 

inertial  alcne,  Doppler  alone,  air  data  alcne.  However,  if 
the  computer  malfunctions,  then  only  manual  backups  remain. 
In  a distributed  system  there  are  many  options  for  the 
designer.  Fcr  example,  there  may  ue  a spare  computer  which 
can  be  activated  and  which  either  has  in  its  memory  pregrams 
fcr  the  vital  functions  or  can  read  the  program  ir.tc  its 
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memory  from  an  auxiliary  memory. 

Another  solution  would  be  to  have  tue  vital  functions  in 
two  computers  so  that  if  one  fails,  the  ether  can  carry  on, 
much  like  a pilot  and  copilot  function  on  transport 
aircraft . 

E.  GRACEFUL  DEGRADATION 

Graceful  Degradation  refers  precisely  to  the  concept 
that  one  or  more  failures  in  the  system  degrade  the 
performance  tut  do  net  totally  cause  the  system  to  collapse. 
A distributed  system,  particularly  if  it  uses  cptical 
interfaces  between  components,  has  the  ability  to  degrade 
qracefully.  If  systems  elements  are  connected 
electronically  they  are  not  as  well  isolated  and  a serious 
failure  in  a system  connected  to  tne  bus  can  cause  a failure 
on  the  bus,  which  makes  the  entire  system  inoperable.  An 
cptical  Lus  is  not  nearly  as  vulnerable  because  of  the  light 
signal  isclates  tne  systems  electronically. 

A systems  designer  has  many  options  to  create  a system 
whose  total  failure  is  very  unlikely.  Duplicating  or 
triplicating  systems  elements  would  be  an  obvious  way. 


IX.  ECONOMIC  ANALYSIS 


A.  SUMMARY  OF  ECONOMIC  ANALYSIS  ME"' EOF 

When  estimating  the  costs  of  alternative  engineering 
implementations  using  a still  emerging  technology,  like  large 
scale  integrated  circuitry,  performing  the  economic  analysis 
begins  by  making  projections  into  the  future  about  a set  of 
significant  variables.  In  the  case  of  LSI,  some  of  these 
would  be  propagation  delay,  gate/chip,  cost/gate,  failure  rate, 
cost/connection,  etc.  There  in  fact  exist  several  of  these 
significant  variables  that  could  be  identified,  each  one 
having  a point,  and  an  interval  estimate  of  their  value  fore- 
cast at  certain  steps  along  the  future  time  line  being  con- 
sidered. An  exhaustive  analysis  would  seek  to  take  all  possible 
combinations  of  all  possible  values  of  the  variables  to  measure 
the  costs  and  uncertainties  in  those  costs  of  the  alternative 
engineering  implementations.  This  type  of  analysis  can  quickly 
lose  any  intuition  it  might  have  built  for  a decision  maker 
in  a mass  of  data  points. 

An  alternative  approach,  and  the  one  selected  for  this 
report,  is  to  first  create  a set  of  broad  risk  categories 
that  relate  to  the  problem  being  analyzed,  and  to  generate 
from  them  scenarios  each  with  a neutral  (or  most  likely) , a 
slightly  optimistic,  and  a slightly  pessimistic  case.  The 
outcome  of  these  three  cases  is  a set  of  three  values  for 
certain  key  variables.  The  cost  of  the  alternative  engineer- 
ing implementations  is  then  based  on  this  outcome.  What 
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this  narrative  scenario  approach  accomplishes  for  a decision 
maker  is  a projection  into  the  future  structured  around  some 
managerial ly  meaningful  categories.  The  constants  across 
the  scenarios  are  the  competing  engineering  implementation 
philosophies  and  the  risk  category  structure.  In  structuring 
the  scenarios  it  is  important  to  free  the  implementation 
alternatives  from  the  risk  categories  to  bo  able  to  see  how 
they  then  stand  against  each  other  across  a spectrum  of  risk. 

A decision  maker  can  then  see  how  each  competing  alternative 
would  fare  cost-wise  in  possible  futures  that  have  more  mean- 
ing than  might  be  drawn  out  of  a mass  of  data  points. 

For  the  economic  analysis  of  this  report  alternative 
avionics  computer  architectures,  each  embodying  LSI  technology, 
will  be  placed  in  the  context  of  two  possible  scenarios  devel- 
oped on  the  milestone  path  of  the  VSTOL  aircraft.  Each  scen- 
ario structures  the  risk  inherent  in  the  future  into  four 
broad  categories.  The  first  category  will  be  called  the 
semiconductor  industry  as  related  to  technological  changes  in 
and  the  marketing  of  microcomputing  devices.  The  second  cate- 
gory is  the  systems  acquisition  strategy  for  future  avionics 
in  light  of  OMB  circular  A109  and  with  regard  to  source 
selection  and  contract  incentive  structure.  The  third  cate- 
gory is  the  maintenance-manpower  system  which  entails  repair- 
discard,  level  of  maintenance,  and  labor  mix  possibilities. 

The  last  category,  aircraft  employment,  addresses  not  only 
the  number  of  VSTOL  aircraft  projected  as  a base  for  operating 
and  support  costing  and  the  rate  of  aircraft  production,  but 
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from  which  ship  typos 


also  their  method  of  employment,  i.e.,  from  which  ship  typos 
they  will  be  operated  and  maintained.  The  implication  of  the 
last  category  is  that  ship  types  capable  of  VSTOL  flight 
operations  may  not  be  capable  of  complete  maintenance  or  of 
multi-mission  operational  support. 

The  two  scenarios  will  follow  a baseline  description  of 
the  VSTOL  program  and  the  four  risk  categories.  The  baseline 
develops  the  necessary  background  for  structuring  the  two 
scenarios  and  their  neutral  (most  likely) , slightly  optimistic, 
and  slightly  pessimistic  cases.  This  economic  analysis  pro- 
cess is  pictured  in  Figure  9-1. 


D. 


BASELINE 


As  stated,  the  four  categories  of  risk  briefly  are,  the 
semiconductor  industry,  the  systems  acquisition  strategy, 
the  maintenance-manpower  system,  and  the  employment 
possibilities . 

1.  The  Semiconductor  Industry  as  Related  to  Technological 

Advance  and  Marketing  of  Microcomputing  Devices 

The  first  chapter  of  this  report  generalized  the  impact 
of  large  scale  circuit  integration  on  computing  technology. 

A more  detailed  account  with  particular  reference  to  techno- 
logical change  and  marketing  of  microcomputing  devices  will 
be  discussed  here. 

The  primary  effect  on  the  market  of  LSI  has  been  to  open 
up  new  applications  areas  for  microcomputing  devices.  In 
particular,  is  the  opening  up  of  three  areas  that  can  be 
broadly  classed  as  the  process  control  market,  the  consumer 
market,  and  the  small  business  or  hobbyist  general  purpose 
personal  computer  market.  The  thread  common  to  all  of  these 
markets  is  the  implementation  of  what  was  previously  electro- 
mechanical analog  logic  and/or  custom  designed  electronic 
circuitry  by  general  purpose  digital  computing  logic  inte- 
grated to  one  or  a few  semiconductor  chips. 

Before  briefly  reviewing  the  history  of  these  microcom- 
puting devices,  reflection  on  the  life  cycle  of  computer 
products  in  general  reveals  a reasonably  standard  sequence 
of  events.  Technological  advance  in  circuitry  design  occurs 
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first,  followed  by  exploitation  in  the  form  of  a product  made 
possible  by  improvements  in  manufacturing  technology.  The 
product,  if  accepted  in  the  market,  begins  to  find  further 
applications.  It  is  gradually  enhanced  in  performance  to 
meet  these  new  found  applications,  creating  a family  of  com- 
puters. Peripheral  equipment  and  software  development  tools  are 
developed  by  the  parent  company.  If  the  product  really  makes 
an  impact  in  the  market,  like  the  DEC  PDP8  did  in  terms  of 
helping  to  create  the  minicomputer  market,  other  companies 
specializing  in  peripherals,  maintenance,  or  software  support 
and  applications  spring  up.  The  basic  product  is  upgraded 
until  it  is  no  longer  economic,  and  then  emulated  as  transi- 
tion to  a replacement  computer  product  occurs. 

With  this  in  mind,  concentrating  on  the  traditional  Von 
Neumann  building  blocks  of  the  digital  computer,  the  processor, 
the  memory,  the  input/output,  and  the  timing  circuitry  provides 
a framework  for  describing  the  technological  change-marketing 
paths  that  have  appeared  to  date  and  that  are  projected  to 
appear  in  the  two  scenarios  of  this  report  for  LSI  computing 
devices. 

A semiconductor  company,  Intel  Corporation,  already  a pro- 
ducer of  LSI  memories  was  the  strongest  initiator  in  the 
microprocesser/microcomputer  device  market  . Their  Intel  4004  , 
a four-bit  word  length  device,  was  the  first  commercially 
successful  microprocessor.  It  was  and  is  used  in  limited 
scope  process  control  and  some  consumer  products  like  pong 
games.  As  a designer's  tool  it  required  a read  only  memory 
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chip  to  provide  space  for  the  controlling  program.  Timing 
circuits,  and  input/output  interface  devices  were  also 
required.  As  more  circuitry  could  be  put  on  a chip  because 
of  semiconductor  manufacturing  technology  improvements,  the 
question  presumably  became  for  Intel,  "For  commercial  success, 
should  all  the  building  blocks  of  a digital  computer  be  placed 
on  one  chip  or  should  the  single  chip  processor  be  made  more 
capable  in  terms  of  word  length,  processing  speed  and  instruc- 
tion set?"  Empirically  the  evidence  shows  that  the  processor 
was  made  more  powerful  first,  with  the  introduction  of  the 
Intel  8008,  an  8-bit  word  length  processor,  and  then  with  the 
most  commercially  successful  microprocessor  to  date,  the 
Intel  8080.  Several  other  microprocessors  entered  the  market, 
of  course,  the  AMD  2900,  the  Motorola  6800,  the  Zilog  Z-80, 
the  LSIll,  and  now  the  16-bit  Texas  Instruments  TI9900,  to 
name  a few.  The  significance  of  the  last  three  examples  named 
is  that  they  are  enhancements  over  the  8080  and  that  they 
came  prior  to  the  Intel  8048  family,  the  first  complete  com- 
puter-on-a-chip  on  the  market  and  also  prior  to  the  TI9940, 
also  a computer-on- a-chip.  Also  of  significance  is  the  fact 
that  Intel  announced  the  8085,  a fifty  percent  speed  enhance- 
ment of  the  8080  at  the  same  time  as  the  8048  family. 

Several  reasons  can  be  postulated  as  being  behind  this 
technological  change-marketing  path.  The  first  is  that  semi- 
conductor read  only  memory  chips  to  hold  the  applications 
program  were  already  available  from  separate  vendors. 

Another  is  that  when  a process  control  is  designed  in  the 
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framework  of  digital  computing  logic  it  is  done  so  with  the 
traditional  Von  Neumann  computer  building  blocks  in  mind. 

The  process  is  first  described  by  the  design  engineer  in  terms 
of  data  flow,  i.e.,  input  signals  being  transformed  by  func- 
tional operators  into  output  signals.  The  job  is  then  sized 
in  terms  of  execution  times  and  memory  space  as  separate 
constraints.  The  result  is  separate  implementation.  As 
applications  are  worked  out  using  digital  computing  logic, 
memory  size  can  be  incremented  by  adding  memory  chips  in  much 
the  same  way  that  memory  is  added  to  a general  purpose  main 
frame  or  minicomputer  as  applications  are  developed.  Now  that 
the  use  of  single  and  few  chip  microprocessors  has  made  its 
initial  impact  on  the  applications  market,  the  computer-on- 
a-chip  with  its  fixed  resident  read  only  memory  fits  the 
applications  that  are  becoming  more  defined  in  the  literature 
as  to  execution  time,  memory  size,  and  instruction  set 
manipulation. 

Restated  another  way,  the  microprocessor  impacted  the 
market,  the  market  in  turn  then  impacted  the  microprocessor 
development  path.  As  a company  makes  techno  log ica 1 headway 
as  did  Intel  with  the  first  microprocessors , that  technology 
is  exploited  for  the  payback  to  the  investment  as  outlined  by 
the  S • N ✓ CNR  + CR  • N formula  of  the  early  chapters  in  this 
report.  After  the  first  device  hits  the  market  the  strateqy 
generally  is  to  follow  with  performance  enhancement  as  the 
users  become  more  familiar  with  the  implementation.  As  other 
companies  come  into  the  market  with  even  faster  performing 
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devices  as  did  Zilog,  DEC,  Texas 
the  lead  company , in  this  case  Intel,  generally  begins  to  dis- 
criminate its  product  line  by  the  support  system,  and  then  by 
some  technological  leap-frog  that  is  intended  to  put  distance 
between  itself  and  the  others.  The  last  tew  paragraphs  de- 
scribe some  of  the  several  reasons,  besides  those  of  semicon- 
ductor manufacturing  technology,  that  most  probably  were  behind 
the  chronology  of  introduction  of  the  Intel  R04S  single  chip 
computer,  i.e.,  after  the  enhancements  to  the  original  suc- 
cessful microprocessors. 

One  other  aspect  of  the  market  that  bears  mentioning  is 
the  development  in  the  licensing  of  a product 's  technology 
(a  concept  pointed  out  in  the  Computer  Family  Architecture 
report,  referred  to  in  the  next  section,  as  most  probable 
he.  ling  the  key  to  much  of  the  cost  differential  in  most  actual 
negot • ited  product  selections).  In  the  earlier  days  of  com- 
puting, and  to  this  day,  IBM  held  near  and  dear  to  its  tech- 
nological secrets  as  it  gained  its  dominant  position  in  the 
market.  Now  companies  will  license  the  use  of  trade  secrets 
to  competitors.  The  most  relevant  examples  are  the  license 
agreement  Norden,  a division  of  United  Technologies,  has  with 
Digital  Equipment  Corporation  to  produce  the  military  versions 
of  the  rDP/LSIll's,  the  ROI.M  license  with  Data  General  Nova 
Division,  and  recently  the  AMD  license  agreement  with  Intel 
to  use  Intel  design  masks  to  produce  SOSOA's.  Two  other 
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important  ones  stand  out.  The  first  is  to  obtain  a quick 
return  for  the  parent  company  on  a technological  implementa- 
tion in  a high  rate  of  technological  change  area  in  the  face 
of  the  10^  dollar  development  cost  for  the  device,  referred 
to  early  in  this  report.  The  second  is  to  increase  the  base 
of  use  of  a product  both  in  number  of  devices  and  number  of 
sources  and  hence  gain  a wider  acceptance  of  the  product  as 
an  industry  standard. 

In  summary,  a major  point  in  this  technological  change- 
marketing path  baseline  is  the  development  of  the  understand- 
ing that  the  applications  market  has  an  influence  on  the 
technological  form  of  a product  along  with  the  physical  laws 
governing  the  shape  of  that  product  and  the  manufacturing 
technologies  that  produce  it.  What  the  scenarios  will  try 
to  structure  then  from  this  risk  category  is  two  possible  con- 
tinuations of  the  established  trends  so  as  to  be  able  to 
structure  the  available  technology  packages  and  their  support 
systems  for  VSTOL  avionics  with  a probable  baseline  freeze 
of  1985. 


2.  The  Systems  Acquisition  Strategy 

The  previous  risk  category  primarily  addressed  the  pro- 
ducers. This  category  addresses  the  user  side.  The  thrust 
from  users  in  any  high  technology  area  is  to  somehow  create 
a set  of  standards  so  as  to  minimize  repetitious  investment 
in  capital  equipment  and  cost  of  ownership.  A buffer  of 
standardization  is  created  to  protect  the  user  from  the 
rapid  pace  of  technological  change. 

Currently  several  different  movements  amongst  the  users 
of  computing  devices  exist.  First,  within  the  military 
services,  the  Military  Computer  Family  Architecture  ( CFA) 
committee  has  established  an  analysis  which  outlines  what  a 
military  computer  family  requirement  would  be  with  regard  to 
a standard  instruction  set  and  software  support  and  then  goes 
on  to  show  with  sound  argument  that  the  commercial  PDPll 
commercial  family  satisfies  the  requirement. 

Within  the  Navy  the  Assistant  Secretaries  of  the  Navy  for 
Installations  and  Logistics  and  for  Research  and  Development 
have  sent  out  a joint  memo  dated  30  March  1977  for  comment, 
mapping  out  a short  term  and  long  term  strategy  to  cope  with 
the  proliferation  of  computing  devices.  This  memo  establishes 
for  the  near  term  the  continuation  of  the  UYK7  and  20  in  the 
surface  Navy  as  the  standard  computer  family,  and  the  AYK14, 
a machine  made  in  bit  slice  fashion  from  the  LSI  AMD  2900 's 
and  compatible  with  the  UYK  20,  as  the  Naval  airborne  interim 
standard.  It  calls  for  all  future  microcomputer/microprocessor 
acquisitions  to  be  of  devices  capable  of  implementing  these 
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respective  instruction  sets.  In  the  longer  terra  it  calls  for 
evaluation  of  the  CFA  proposal  in  light  of  the  competing 
AYK14,  UYK7  and  20  interim  standards. 

The  AYK14  currently  has  possible  homes  in  several  Navy 
airborne  projects  (9-1) . 


Project  AYK14  * s 


F18  1600 

LAMPS  III  205 

AV8B  350 

IEWS  300 

TACO MJ AM  80 

HARM  (Avionics)  361 

TASSES  24 

WIDEBAND  DUAL  MODE  1000 

BRAIDS  VARIABLE 

DIFAR  350 

CAINS  IA  1000 

LINK  11  285 

PROTEUS  500 


6255* 


♦while  not  exact  or  official,  these  numbers  are  representative. 


Most  significant  are  the  F/A-18  which  will  have  two  AYK14's 
together  on  a mil  standard  1553  type  bus,  the  LAMPS  Mk  III 
helo  which  will  have  one  AYK14 , the  P3C  Update  III  which  may 
have  an  AYK14  in  network  to  offload  the  at-capacity  central 
computer,  and  the  AV8B , the  advanced  Harrier  for  the  Marine 
Corps.  The  importance  of  these  projects  will  be  seen  in  the 
scenarios.  With  the  exception  of  LAMPS  Mk  III,  the  final 
direction  of  each  of  these  projects  is  not  yet  firm  as  of 
this  writing.  The  ultimate  outcome  of  each  of  these  projects 
is  in  some  measure  tied  in  with  the  VSTOL  concept.  Any  one 
of  a number  of  outcomes  could  occur,  affecting  the  ultimate 
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base  number  of  AY K 1 4 ' s in  the  Navy  system.  This  will  be  a 
key  factor  in  costing  out  the  alternative  computer  architectures 
in  this  report  via  the  scenario — neutral,  optimistic,  pessimis- 
tic case  idea.  That  number,  along  with  the  following  totals 
for  existing  airborne  computers  in  the  Navy,  has  considerable 
meaning  when  reflected  on  in  light  of  the  S • N > CNR  + CR  -N  equa- 
tion inherent  in  LSI  computing  device  development  expressed 
earlier  in  this  report  (9-1). 


Type  of 
aircraft 

Number  of  computers 
per  aircraft 

Number  of 
aircraft 

Total  number 
of  computers 

E2C 

3 

36 

108 

A7D 

1 

400 

400 

A6E 

1 

200 

200 

S3A 

5 

165 

825 

P3C 

1 

150 

150 

F14 

6 

200 

1200 

2883* 

♦while  not  exact  or  official,  these  numbers  are  representative. 

The  connection  of  the  VSTOL  project  with  the  National  Aero- 
nautics and  Space  Administration  also  has  significance  in  terms 
of  the  possible  acquisition  strategies  which  might  come  to  pass. 
In  the  absence  of  a general  aviation  standardization  committee, 
like  the  kind  ARINC  provides  for  commercial  aviation,  NASA  has 
taken  it  on  itself  to  provide  such  a forum.  In  late  1977,  it 
will  initiate  a Request  for  Proposal  (RFP)  for  a general  avia- 
tion computer  based  avionics  demonstrator  with  award  to  be 
made  in  mid  1978  and  delivery  to  occur  in  1980-81  for  evalua- 
tion. Currently  postulated  answers  to  the  RFP  based  on  prelim- 
inary NASA  work  indicate  a multiple  computer  network  on  a 
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bus  like  mil  standard  1553A  or  IEEE  403,  with  a multifunction 
display--not  dissimilar  with  the  F18/F15  solutions  and  the 
homogeneous  alternative  of  this  report.  Form,  fit,  and  func- 
tion standardization  is  being  sought  to  allow  for  advances 
in  technology  much  like  ARINC  standards  for  commercial  avia- 
tion. Although  the  environment  for  a general  aviation  air- 
craft may  not  be  exactly  the  same  as  for  VSTOL  (although 
corporate  type  jets  are  in  use  by  the  Coast  Guard  and  reach, 
in  commercial  use,  the  edge  of  the  speed  and  maneuverability 
envelopes  of  their  military  sub-sonic  counterparts) , the 
degree  if  any  to  which  the  NASA  effort  links  with  the  VSTOL 
effort  could  influence  the  cost  of  the  implementation  alter- 
natives. This  effect  will  be  addressed  in  the  scenarios. 

Even  if  the  actual  hardware  is  somewhat  different,  the  concept 
of  implementation  and  the  interface  standards  might  extend 
across  general  aviation  and  military  applications. 

Another  very  significant  point  in  the  acquisition  strategy 
revolves  around  0MB  circular  A109.  This  systems  acquisition 
circular  among  other  things  requires  that  early  attention  of 
industry  be  invited  by  a statement  of  mission  needs  vice 
specific  hardware  specifications  in  the  RFP . The  impact  of 
this  is  that  concept  definition  and  validation  are  essentially 
obtained  via  industry  participation  with  specific  hardware 
implementation  not  delineated.  Prior  to  OMB  A109  a definite 
piece  of  hardware  and  consequently  its  inherent  technological 
implementation  became  locked,  very  early  in  the  acquisition 
process,  into  detailed  specifications.  In  interviews  with 
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airframe  manufacturers  and  Navy  software  support  activities, 
much  of  the  "software  cost  problem"  is  viewed  as  really  a prob- 
lem of  correct  software  but  for  a hardware  specification  over- 
come by  the  events  of  technological  change  and  the  resultant 
specification  changes. 

A position  of  this  study  made  apparent  by  its  very  nature 
and  more  specific  in  the  scenarios,  is  that  if  the  Navy  lab 
structure,  i.e.,  the  labs  and  their  research  arms  in  college 
campuses,  private  think  tanks,  and  public  institutions  are 
considered  as  "industry,"  a wider  definition  of  A109,  without 
losing  its  spirit  and  intent,  opens  up  a number  of  possible 
acquisition  strategies.  As  pointed  out  by  this  report,  the 
nature  of  the  aircraft  avionics  problem  and  its  digital  com- 
puter implementation  is  such  that  very  basic  and  useful  work 
can  be  done  via  the  Navy  lab  structure  on  the  problem  in  terms 
of  data  flow,  control  flow,  higher  order  language,  coding  of 
algorithms,  architectural  considerations  and  life  cycle  cost 
modeling . 

If  one  first  abstracts  across  several  aircraft,  as  is  done 
in  this  report,  a set  of  mathematical  structures  relating  the 
flow  of  data  is  obtainable.  By  doing  this  a core  (navigation, 
ballistics,  etc.)  is  obtained  that  would  be  common  to  all  the 
mission  variants  of  an  aircraft  like  VSTOL.  Each  aircraft 
begins  with  that  core  and  adds  to  it  the  mission  variants. 
Beginning  with  that  idea  the  process  can  be  pictured  as 
emanating  from  the  center  of  concentric  circles  (Figure  9-2). 
Eventually  the  implementation  of  these  functions  occurs.  In 
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the  past  in  planes  like  the  F4  it  was  in  analog  fashion. 

Now  these  mathematical  structures  are  implemented  by  digital 
computing  logic.  This  core  would  establish  the  way  in  which 
the  mission  variants  and  particularly  what  are  called  the 
embedded  processing  elements  would  interface,  both  initially 
and  then  across  time  as  the  system  grew  to  meet  added 
requirements . 

The  significance  of  this  appears  when,  from  empirical 
evidence,  it  is  seen  that  the  aircraft  industry  is  organized 
by  airframe  manufacturers,  engine  makers,  and  various  avionics 
and  electrical  shops  that  relate  to  specific  mission  variants 
or  avionics  functions.  There  are  flight  control  shops,  radar 
shops,  electronic  warfare  shops,  weapon  systems  shops,  etc. 

Each  shop  as  technology  users  will  be  exploiting  LSI  technol- 
ogy and  replacing  large  amounts  of  circuitry  by  microprocessors 
and  read  only  memory,  in  what  is  called  embedded  fashion,  in 
their  own  piece  of  equipment.  By  going  back  to  the  concentric 
circles  it  can  be  seen  that  several  different  approaches  to 
acquisition  can  be  taken.  The  avionics  shops,  airframe  and 
engine  manufacturers,  can  be  allowed  to  de  facto  decide  what 
the  core  looks  like  by  impinging  toward  the  center  of  the  con- 
centric array  from  the  outside.  Or  the  user  can  define  the 
core  first  as  ARINC  does  for  the  commercial  aviation  world, 
and  allow  the  circles  to  grow  outward  in  an  orderly  fashion 
from  the  central  core.  Looking  closely  at  commercial  aviation, 
ARINC,  a third  party  created  by  mutual  consent  of  the  airlines 
defines  this  core  and  an  orderly  fashion  for  interfacing  to  it. 
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NASA  is  now  attempting  to  do  this  for  general  aviation.  If 
the  VSTOL  project  managers  are  thought  of  as  the  users,  then 
the  Navy  lab  structure  could  be  viewed  as  the  third  party  in 
the  acquisition  strategy  to  define  that  core.  Note  that  this 
does  not  mean  definition  in  terms  of  specific  hardware,  on 
the  contrary  it  would  be  in  more  abstract  terns  of  control 
and  data  flow,  execution  times,  memory  requirements,  bus 
interface  protocols,  HOL  algorithms,  etc.  This  would  structure 
then  how  the  mission  variants  of  the  plane  and  embedded  pro- 
cessing elements  would  interface  with  each  other  and  the  core. 
As  with  ARINC,  this  would  be  free  of  hardware  implementation 
and  allow  technological  change  to  be  captured  up  to  the  point 
of  baseline  freeze.  What  the  scenarios  and  their  neutral, 
optimistic,  and  pessimistic  cases  will  do  is  hypothesize 
possible  acquisition  paths  and  see  how  the  cost  of  the  two 
architectural  implementations  of  this  report  would  be  affected. 
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3.  Maintenance-Manpower  System 

In  an  economic  analysis  it  is  generally  intended  that  the 
fallout  of  the  analysis  is  the  repair-discard,  level  of 
maintenance,  and  labor  mix  results.  However  it  is  often  the 
case  that  organizational  inertias  or  organizational  optimiza- 
tion of  other  criteria  than  the  economics  of  competing 
engineering  alternatives  prevail  over  the  analysis  results. 
This  risk  category  therefore  lays  out  some  considerations  that 
are  later  structured  into  possible  outcomes  in  the  scenarios. 

As  exhibited  in  articles  in  the  electronic  engineering 
trade  journals,  there  is  concern  over  job  description  because 
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of  the  fact  that  electrical  circuit  implementation  is  becoming 
in  many  areas,  particularly  process  control,  one  of  digital 
computing  logic.  The  emotions  attached  to  this  can  be  expressed 
by  the  quote  of  one  aerospace  industry  engineering  head  who 
stated  emphatically  that  he  didn't  have  any  computer  program- 
mers, he  had  aerospace  engineers  that  were  called  upon  to 
program.  The  trade  magazines  such  as  Digital  Design,  Elec- 
tronics, Spectrum,  etc.,  have  begun  to  run  articles  that 
address  the  electronic  engineers’  outlook  with  respect  to  this 
microprocessor/microcomputer  phenomenon . 

The  relationship  to  the  Navy  maintenance-manpower  system 
becomes  visible  through  the  viewing  of  businesses  that  are 
recognizing  that  their  very  organizational  structures  are  being 
impacted  by  LSI  technology  in  digital  computing  logic  form. 

The  separation  between  the  computer  science  departments  and 
the  other  engineering  design  departments  is  being  obscured  as 
the  electronic  engineers  are  being  required  to  know  digital 
computing  logic  and  programming,  and  vice  versa.  Although 
the  Navy  maintenance-manpower  system  is  a user  vice  designer 
system,  a knowledge  of  the  implementation  of  circuitry  by 
digital  computing  logic  is  a requirement  for  understanding 
its  maintenance.  It  is  reasonable  to  expect  that  just  as  the 
electronics  engineer  design  trades  are  impacted  by  LSI  tech- 
nology, so  will  the  maintenance  trades. 

The  meaning  of  this  to  the  Navy  is  simply,  or  not  so 
simply,  NEC  and  rating  restructuring.  The  not  so  simply  comes 
in  the  sense  that  a maintenance-manpower  system  is  not  created 
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overnight.  Just  as  the  electronics  engineer  is  concerned 
with  his  educational  preparation  and  the  protection  of  this 
human  capital  investment  in  the  face  of  LSI  digi- 
tal computing  technology,  so  will  the  maintenance  man.  LSI 
digital  computing  technology  might  dictate  via  economic 
analysis  that  a solution  to  the  maintenance-manpower  system 
structure  be  one  group  of  people  that  understands  built-in- 
test design  and  operation  at  the  organizational  level  of 
maintenance,  another  that  understands  circuit  board  logic 
testing  at  the  intermediate  level  of  maintenance,  and  those 
that  understand  digital  computer  program  design,  analysis  and 
troubleshooting  at  the  depot  level.  Restructuring  NEC's  and 
ratings  to  accomplish  this,  independent  of  whether  the  system 
is  in  an  airplane,  a ship,  or  a submarine,  cannot  be  done 
instantaneously.  It  may  not  even  be  recognized  as  a positive 
goal  by  the  manpower-personnel  planning  systems  since  the 
separation  of  maintenance  ratings  by  warfare  specialty  creates 
other  positive  intra-  and  inter-organizational  relationships. 
The  scenario  method  is  used  therefore  to  address  the  possible 
relations  of  LSI  to  the  maintenance-manpower  system  and  the 
costing  fallout,  vice  assuming  the  normative  case. 

Existing  evidence  that  there  is  recognition  of  the  possible 
effect  of  LSI  on  the  maintenance-manpower  system  is  the  joint 
service  symposium  on  Automatic-Test-Equipment  held  in  June 
1977.  Each  service  presented  its  programs  in  the  area,  sol- 
iciting inputs  from  industry  as  well.  Some  possible  relevant 
developments  that  could  occur  out  of  this  tri-service  program 
will  be  considered  in  the  scenarios. 
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Another  aspect  of  maintenance  of  no  am. ill  significance 
is  the  sot tware  development  and  support  of  t lu'  digital  compu- 
ting logic  applications  software.  There  is  more  than  one  way 
to  develop  and  support  the  software.  1!  the  aircraft  avionics 
hardware  and  applications  software  procurement  is  bundled, 
support  of  that  software  could  come  from  that  source.  If  the 
procurement  is  unbundled,  a software  vendor  or  avionics  shop 
could  provide  it.  The  Naval  Air  Systems  Command  has  created 
its  own  applications  software  support  activities  in  the  Naval 
Air  Development  Center  at  Warminster,  Pa.,  the  Missile  Test- 
Center  at  Point  Mugu,  California,  and  the  Naval  Weapons  Center, 
China  Lake.  They  handle  the  operational  flight  programs  (OFP) 
for  the  ASW,  high  performance  fighter,  and  attack  aircraft 
respectively.  The  current  thrust  is  to  pass  to  those  software 
support  activities  control  of  the  appl i ea t ions  software  after 
a certain  point  of  testing  in  development.  This  task  becomes 
more  difficult  as  the  use  of  digital  computing  logic  imple- 
mentation and  its  required  software  spreads  throughout  the 
aircraft  in  the  form  of  microcomputer/mieroprocessor  based 
systems . 

The  impact  addressed  in  the  scenarios  is  the  effect  in 
terms  of  the  type  of  software  development  and  support  systems  that 
might  be  decided  upon  as  outlined  in  the  general  i .’.it  ion 
of  cost  issues  in  this  report. 

4.  Employment 

rfi«*  VSTOL  aircraft  as  with  the  LAMPS,  and  its  drone  pre- 

i he  DASH , is  more  closely  intertwined  with  the  parent 
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ship  that  supports  it  operationally  and  for  maintenance.  The 
question  of  how  much  processing  and  display  equipment  the  ship 
and  aircraft  should  host  respectively  is  heightened  in  the 
case  of  VSTOL  because  of  the  take-off  gross  weight  restrictions 
of  the  VSTOL  technology.  Any  discussion  of  VSTOL  ultimately 
becomes  a discussion  of  the  Navy  surface  ship  force  structure, 
again  no  simple  discussion. 

Currently  the  Navy  force  structure  is  debated  around  three 
force  levels,  a 400,  500,  and  600  ship  Navy;  and  two  force 
mixes,  sea  control  and  power  projection.  To  understand  the  two 
mixes  one  must  first  understand  the  two  most  basic  roles  of 
the  Navy.  The  first  is  the  projection  of  strike  power  inland 
as  embodied  in  the  strike  carrier  task  forces  and  the  nuclear 
strike  cruisers.  The  second  is  the  control  of  the  sea  lanes 
as  embodied  in  the  smaller  escort  vessels  and  the  hypothesized 
sea  control  ship  now  called  the  VSS  or  VSTOL  support  ship, 
about  the  size  of  the  Amphibious  Assault  Helicopter  Carrier 
(LPH) . Alternative  force  structures  were  developed  by  this 
author  from  Navy  testimony  in  Congress,  a National  Security 
Council  study,  and  two  Congressional  Budget  Office  working 
papers . 

The  outcome  of  these  alternative  forces  goes  into  providing 
the  base  number  of  VSTOL  aircraft  that  could  reasonably  be 
expected  to  exist  in  the  1991-2001  time  frame  and  hence  the 
number  of  airborne  computers.  The  maintenance  structures  that 
could  reasonably  be  expected  to  exist  wore  also  developed  from 
these  alternative  force  structures. 
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C.  SCENARIO  (AIRBORNE  STANDARD) 


This  scenario  is  meant  to  be  interpreted  in  the  metaphori- 
cal sense.  Its  intent  is  to  relate  events  in  time  so  as  to 
establish  how,  most  likely,  slightly  optimistic  and  slightly  pessi- 
mistic cases  might  be  generated  from  a collection  of  rea 1 istic  events . 

The  scenario  begins  in  the  fall  of  1977.  The  Naval  Post- 
graduate School's  report  on  distributed  LSI  microcomputing 
for  VSTOL  avionics  has  been  received  with  interest.  It  is 
read  in  several  places  which  include  the  Naval  Air  Systems 
Command  Avionics  and  Software  Support  Offices  (NAVAIR  533) , 
the  VSTOL  Program  Office  (PMA  269) , and  as  an  input  to  the 
ASN  IL/RD  memo  of  March  1977.  In  November  of  1977  the  VSTOL 
RFP  for  conceptual  studies  goes  out.  The  NASA  RFP  for  the 
general  aviation  computer  based,  multiplexed  bus,  and  multi- 
function display  demonstration  also  goes  out  at  about  the 
same  time. 

In  December  of  1977  Norden,  a division  of  United  Technolo- 
gies, makes  first  deliveries  of  the  LSI11M,  a military  version 
of  the  DEC  LSI11,  announced  in  the  summer  of  1977  as  an 
embedded  use  companion  for  their  PDF11/34M.  The  military 
Computer  Family  Architecture  committee  which  recommended  the 
PDPll  family  for  the  military  form,  fit,  and  function  specifi- 
cation uses  this  to  add  emphasis  to  their  analysis.  The 
LSI11M  instruction  set  is  a subset  of  the  PDP11/34M,  would  be 
compatible  for  embedded  use  in  a bused  network  with  the  PDPll 
family,  and  uses  the  existing  PDP11/DEC  family  software 
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development  and  support  systems  available  from  a multitude  of 
commercial  sources  and  already  in  place  in  many  military 
activities. 

Intel  Corporation's  commercial  success  with  the  8080 
microprocessor  family  continues.  The  8080  family  as  enhanced 
in  the  summer  of  1977  by  the  speed  improvements  (a  factor  of 
2)  of  the  8085  is  marketed  as  the  ad  hoc  industrial  process 
control  and  consumer  market  standard.  This  marketing  position 
is  furthered  in  the  fall  of  1977  by  the  licensing  and  second 
sourcing  of  the  8080  family  by  National  Semiconductor  and 
AMD  in  the  form  of  chip  sets  families  and  single  board  compu- 
ters. Other  successful  entrants  in  the  microprocessor/micro- 
computer  market  in  terms  of  accumulated  experience  (devices 
sold)  are  the  Motorola  6800,  an  8-bit  word  length  microprocessor, 
and  the  Texas  Instruments  9900,  a 16-bit  word  length  micro- 
processor, all  single  or  two  chip  microprocessors  which  also 
provide  the  base  for  those  companies'  single  board  microcomputers . 

From  the  fall  of  1977  to  mid  1979  when  the  RFP  for  VSTOL 
avionics  advanced  development  (concept  definition  and  valida- 
tion) is  made,  the  technological-marketing  path  the  micropro- 
cessor/microcomputer industry  has  taken  is  one  of  exploitation 
of  circuit  integration  at  the  level  of  the  classical  computer 
building  blocks  of  processor,  memory,  input/output,  and  timing 
devices.  Memory  technology  in  particular  progresses  on  paths 
different  than  semiconductor  processor  technologies  so  that 
magnetic-bubble,  floppy  disc,  and  holigraphic  memory  forms 
provide  alternatives  for  implementation,  particularly  for 


random  access  mass  oi  block  memory.  Because  of  systems 
designers'  desire  for  flexible  memory  size,  the  single  chip 
semiconductor  computer  in  mid  1979  has  not  become  the  dominant 
industry  implementation  for  process  control,  the  consumer 
market,  or  the  general  purpose  microcomputer. 

The  single  chip  semiconductor  computer  is  however  a limited 
commercial  success  by  mid  1979  at  the  4,  8 and  16-bit  word 
length  with  a resident  memory  capacity  of  4K  words  ROM  and 
a rated  throughput  of  0.5  million  instructions  per  second. 

By  1985  it  is  anticipated  that  the  single  chip  computer  will 
have  replaced  the  microprocessor  plus  separate  read  only  mem- 
ory chip  as  the  implementation  for  process  control  and  the 
consumer  market  at  the  8 and  16-bit  word  length  with  a resi- 
dent memory  capacity  of  16K  words  ROM  and  a rated  throughput 
of  1 million  instructions  per  second.  It  will  not  however  be 
the  primary  implementation  for  the  general  purpose  microcom- 
puter. Intel,  Motorola  and  Texas  Instruments  remain  the 
dominant  forces  in  these  markets  and  their  8080/8048,  6800, 
and  9900/9940's  the  dominant  families. 

The  ASN  IL/RD  in  mid  1978  accepts  with  minor  modification 
the  mid  term  and  long  term  strategy  indicated  in  their  memo 
of  30  March  1977.  The  Computer  Family  Architecture  committee 
with  the  growing  use  of  the  LSI11M  receives  endorsement  of  the 
PDP11  family  in  mid  1978  as  the  basis  for  a military  computer 
family.  The  AYK14  and  UYK7  and  20  programs  receive  a DOD 
variance  endorsement  however  to  proceed  in  parallel,  as  already 
established,  for  their  respective  Navy  shipboard  and  airborne 
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communities.  A further  evaluation  point  for  the  ASN  IL/RD 
memo  is  set  for  mid  1979.  This  timing  coincides  with  the 
RFP  for  VSTOL  advanced  development  (validation  and  definition) . 

The  structure  of  the  Navy  shipbuilding  program  is  coalesc- 
ing with  the  President's  budget  for  FY80,  moving  in  the 
direction  of  a 500  ship  Navy.  Thirty-two  ships  will  be  capa- 
ble of  landing  and  launching  VSTOL  aircraft.  The  avionics 
conceptual  studies  proposals,  replies,  and  awards  show  general 
agreement  that  the  following  ship  types,  CV,  CVN , and  VSS 
(LPH  size  ship),  are  under  review  as  organizational  and  inter- 
mediate level  maintenance  and  multi-mission  operations 
platforms.  The  strike  cruiser  CGSN  is  under  consideration  for 
single-mission  operations  and  organizational  level  support. 

The  maintenance  strategy  is  generally  being  conceived  as  one 
of  built-in-test  (BIT)  monitoring  and  line  replaceable  units 
(LRU)  removal  and  replacement  at  the  organizational  level  with 
the  discard  or  repair  of  modules  decisions  made  at  the  inter- 
mediate level  of  maintenance,  and  further  repair  made  at  the 
depot  level.  LRU  size  is  accepted  as  measured  in  ATK  (ARINC 
air  transport  racks)  dimensions  with  modules  measured  in 
Standard  Electronic  Modules  (SEM2A)  which  are  increments  of 
ATR ' s . 

The  defense  budget  being  formulated  in  mid  1979  for  FY81, 
funds  completely  the  F/A-18  program  production.  The  implica- 
tion of  this  is  that  the  AYK14  will  have  a permanent  home  in 
the  Navy  fighter/attack  aircraft  inventory  with  800  Fl8's 
programmed  for  by  1990  and  about  100  FlB's  programmed  to  be 
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off  the  production  line  by  early  1980.  Additionally,  the  P3C 
Update  111  is  to  be  implemented  by  an  AYK14  networked  with  the 
existing  central  processor  on  a mil  standard  1553  type  bus. 
Both  of  these  decisions  are  in  keeping  with  the  near  term 
strategy  of  the  ASN  IL/RD  memo.  The  AVSB  Harrier  is  dropped 
however  in  favor  of  the  A4M  and  F/A-18,  and  the  coming  VSTOL 
program. 

The  mid  1979  reevaluation  point  for  the  ASN  IL/RD  memo  is 
faced  with  three  complications.  First,  the  CFA  committee 
findings  opting  for  the  PDPll  family  is  solidly  backed  by 
that  families  continued  commercial  success,  particularly  the 
LSI 11  subset.  Second,  the  growing  AYK14  program  has  created 
a significant  investment  in  that  family.  Third,  the  micro- 
processors plus  memory  chips  and  single  chip  microcomputer 
have  proliferated  in  embedded  use  in  weapons  and  tactical 
systems  even  in  the  face  of  the  March  1977  memo.  The  prolif- 
eration is  at  the  point  that  several  types  already  exist  in 
the  Navy  inventory  supporting  such  diverse  tactical  and  weap- 
ons system  implementations  as  tactical  aircraft  landing  gear 
retraction.  Marine  Corps  electronic  battlefield  devices,  and 
guidance  devices  for  remotely  piloted  vehicles.  A non- 
exhaustive  list  of  these  types  are  the  AMD2900,  LSI11M,  the 
Intel  8080,  8085,  8048,  8748,  the  Motorola  6800's  and  the 
TI  9900,  9940's.  The  implication  here  is  the  proliferation 
of  their  respective  software  development  and  support  systems 
and  interfacing  requirements.  Also  complicating  the  issues 
laid  out  in  the  memo  and  its  mid  1979  reevaluation,  is  the 
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inconclusive  nature  of  the  direction  taken  by  the  automobile 
industry  from  the  fall  of  1977  to  mid  1979.  Although  expected 
to  be  very  large  quantity  users  and  hence  prime  movers  in  the 
standardization  of  the  microprocessor/microcomputer  industry, 
the  competition  between  the  big  three  and  also  between  their 
respective  model  divisions  in  terms  of  exploiting  the  LSI 
microcomputer/microprocessor  technology  has  held  up  this 
standardization.  An  ad  hoc  standardization  has  occurred  with- 
in model  divisions.  This  standardization  is  on  the  basis  of 
an  8-bit  word  length  (with  the  exception  of  Chrysler)  by  late 
1978  and  then  on  the  Motorola  6800  at  Ford,  the  Intel  8080  at 
GM,  and  the  TI  9900  at  Chrysler  as  their  respective  standard 
instruction  sets  by  mid  1979.  An  IEEE  488  multiplex  bus  and 
its  protocols  and  interface  standards  are  in  the  concept  stage 
for  production  implementation  by  the  1983-1985  model  year  time 
frame. 

The  importance  of  the  automobile  industries'  position  with 
respect  to  the  military  is  in  the  fact  that  the  temperature 
range  faced  by  electronic  circuitry  in  the  environment  of  the 
automobile  engine  is  a sustained  -75°C  to  +450°C  (9-2),300°C 
more  than  that  required  by  mil  specs  for  LSI/IC's.  Hence, 
the  automobile  industry  as  a potential  10  million  unit  per 
year  user  of  microprocessor /microcomputer  based  process  con- 
trol systems  could  by  the  volume  of  their  use  remove  the  extra 
factor  of  2 to  3 the  military  currently  pays  for  its  micro- 
processor/microcomputer devices.  Additionally,  the  automobile 
makers  could  create  the  instruction  set,  interface,  bus  and 
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protocol,  and  power  standards  in  volume  which  general  aviation 
and  the  military  could  accept  as  their  own. 

The  NASA  contract  for  a demonstration  general  aviation 
avionics  is  let  in  April  78  in  answer  to  the  late  1977  RFP . 

By  1980-81  the  demonstrator  is  in  operation  using  a mil  stand- 
ard 1553  type  of  bus,  and  a distributed  network  of  Intel  8080 
family  microprocessors  plus  ROM  chips  type  of  architecture, 
and  a multi-function  display. 

In  light  of  these  events,  in  particular  the  growing  AYK14 
base,  and  the  influence  of  the  ASN  RD/IL  memo,  the  RFP  for 
VSTOL  advanced  development  avionics  definition  and  validation 
is  structured  so  as  to  indicate  selection  of  the  LSI  bit  slice 
AYK14  family  as  the  airborne  computer  in  VSTOL.  An  additional 
anticipation  in  mid  1979  from  the  RFP  is  that  the  HSX,  and  VPX 
would  be  built  from  the  same  AYK14  family  as  the  VSTOL.  As 
a minimum  then,  a NAVAIR  standard  airborne  computer  family 
emerges.  It  is  also  anticipated  that  the  embedded  micropro- 
cessors and  single  chip  computers,  even  if  procured  from 
separate  sources,  be  made  to  conform  with  the  AYK14  standard 
as  to  word  length,  instruction  set,  and  interface  on  a mil 
standard  1553  type  bus  with  either  a shielded  twisted  pair  or 
fiber  optic  implementation.  It  is  further  outlined  in  the 
RFP  that  this  AYK14  family  be  targetable  from  the  DOD  HOL. 

With  this  in  mind,  the  VSTOL  program  avionics  advanced 
development  definition  and  validation  proceeds  in  early  1980. 

Additional  events  between  1980  and  1985  affect  the  results 
of  this  process.  One  is  the  Navy  part  of  the  Tri-Service  Ad 
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Hoc  Automatic  Test  Equipment  Project.  It  is  decided  to  con- 
tinue with  the  VAST  system  concept  incorporating  the  AYK14 
family  into  it. 

Electronics/avionics  technicians*  like  their  commercial 
counterparts,  begin  to  develop  skills  in  the  fundamentals  of 
digital  computing  as  a part  of  the  recognition  by  the  Naval 
Training  Commands  of  the  similarities  in  engineering/maintain- 
ing microcomputing  devices  that  cross  traditional  rates  and 
equipments.  Although  no  rating  consolidations  take  place  in 
this  1980-85  time  frame,  the  climate  is  set  and  some  NEC 
(Navy  Enlisted  Classification  Codes)  are  consolidated  between 
the  ET,  AT,  and  DT  rates. 

This  scenario  will  be  used  to  cost  the  two  architectural 
alternatives,  the  heterogeneous  with  AYK14  LSI  bit  slice 
computers  in  the  avionics  core  networked  with  AYK14  sub- 
system front  end  microprocessors,  and  the  homogeneous  with  a 
distributed  network  of  commercial  microcomputers  made  to  meet 
mil  specs  in  both  the  core  and  subsystem  front  ends.  Each 
system  concept  will  be  assumed  developed  by  an  avionics  com- 
puter shop  during  the  VSTOL  concept  validation  advanced 
development  stage,  rather  than  by  the  lab  structure  or  the 
VSTOL  airframe  manufacturer.  The  most  likely  or  neutral 
case,  slightly  optimistic,  and  slightly  pessimistic  cases  of 
this  scenario  will  develop  costs  around  hypothesized  annual 
rates  of  growth  of  the  AYK14  standard  family  and  commercial 
microcomputers . 
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D.  SCENARIO  (COMPUTER  FAMILY  ARCHITECTURE  STANDARD) 

This  scenario  is  meant  to  be  interpreted  in  the  metaphor- 
ical sense.  Its  intent  is  to  relate  events  in  time  so  as  to 
establish  how  most  likely,  slightly  optimistic  and  slightly 
pessimistic  cases  might  be  generated  from  a collection  of 
realistic  events. 

The  scenario  begins  in  the  fall  of  1977.  The  Naval  Post- 
graduate School's  report  on  distributed  microcomputing  for 
VSTOL  avionics  has  been  read  by  the  Naval  Air  Systems  Command 
Avionics  and  Software  Support  Offices  (NAVAIR  533  and  NAVAIR 
360) , the  VSTOL  Program  Office  (PMA  269) , and  as  an  input  to 
ASN  IL/RD  memo  of  March  1977.  Another  interested  reader  is 
the  NASA  study  group  working  on  the  RFP  (to  be  released  in 
late  1977)  for  a general  aviation  computer  based,  multiplexed 
bus,  and  multi-function  display  avionics  demonstrator.  The 
NASA  RFP  for  the  demonstrator  and  the  Navy  VSTOL  RFP  (to  be 
released  in  late  fall  of  1977)  for  conceptual  studies,  although 
independently  conceived,  are  each  reciprocally  tracked  in 
recognition  of  the  similarity  of  their  purpose. 

The  Military  Computer  Family  Architecture  committee  also 
recognizes  the  similarity  of  purpose  in  the  NASA  and  VSTOL 
RFP's.  Norden  (a  division  of  United  Technologies)  begins 
delivery  of  the  LSIllM  in  December  1977,  a military  version 
of  the  DEC  LSI11,  announced  in  the  summer  of  1977  as  an  embedded 
processing  companion  for  the  PDP11/34M.  The  LSIll  is  a multi- 
chip processor  containing  a subset  of  the  PDP11/34M  instruction 
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set,  supported  by  the  same  software,  and  capable  of  being  used 
in  embedded  fashion  and/or  in  a bused  network  with  the  PDP11M 
family. 

The  two  RFP's  and  the  LSI11M  are  used  as  evidence  by  the 
Military  Computer  Family  Architecture  committee  to  further 
the  position  of  their  analyses  for  a set  of  form,  fit,  and 
function  specifications  around  the  PDP11/LSI11  family.  The 
point  made  is  that  this  family  will  capture  the  existing 
commercially  available  software  development  and  support  sys- 
tems for  nor  only  military  applications  but  also  for  general 
aviation  as  well. 

Intel  Corporation's  commercial  success  with  the  8080 
microprocessor  continues.  The  8080  family  as  enhanced  in  the 
summer  of  1977  by  the  speed  improvements  (a  factor  of  2)  of 
the  8085  is  marketed  as  the  ad  hoc  industrial  process  control 
and  consumer  market  standard.  This  marketing  position  is 
furthered  in  the  fall  of  1977  by  another  second  sourcing  of 
the  8080  family  by  National  Semiconductor  and  AMD  in  the  form 
of  single  chip  processors  and  single  board  computer  packages. 
Other  successful  entrants  in  the  microprocessor/microcomputer 
market  continue  to  be  the  Motorola  6800,  and  the  Texas  Instru- 
ments 9900,  both  single  chip  microprocessors. 

From  the  fall  of  1977  to  mid  1979  when  the  RFP  for  the 
VSTOL  avionics  advanced  development  (definition  and  validation) 
is  made,  the  technological  change-marketing  path  the  micro- 
processor/microcomputer device  industry  has  taken  is  one  of 
rapid  continuation  of  circuit  integration  to  the  point  of 
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having  all  of  the  classical  computer  building  blocks,  processor. 


memory,  input/output,  and  timing  devices  on  one  chip  in  the 
form  of  the  Intel  8048* s,  TI  9940 's,  and  a Motorola  product  as 
yet  undesignated.  Although  alternative  memory  implementations 
such  as  the  magnetic-bubble , floppy  disc,  and  holigraphic 
forms  exist,  the  single  chip  MOS  implementation  dominates  them 
by  mid  1979,  providing  more  than  enough  memory  flexibility  and 
speed  for  applications  designers.  Hence,  the  single  chip 
computer  becomes  the  dominant  implementation  for  process  con- 
trol, the  consumer  market,  and  the  general  purpose  microcompu- 
ter market,  replacing  the  microprocess  plus  ROM  chips  arrange- 
ment. By  mid  1979  it  has  an  8-bit  or  16-bit  word  length  and 
16K  or  8K  bytes  of  ROM  respectively  and  a rated  throughput  of 
0.5  million  instructions  per  second.  By  1985  this  has 
increased  to  an  8-bit  or  16-bit  word  length  each  with  64K 
bytes  ROM  and  a rated  throughput  of  1 million  instructions  per 
second.  This  single  chip  computer  continues  to  dominate  the 
process  control,  consumer,  and  general  purpose  microcomputer 
market  by  1985.  In  fact,  the  hand  held  calculator  and  general 
purpose  microcomputer  market  has  merged  because  of  this  by 
1985.  It  is  not  uncommon  to  see  from  4 to  16  of  these 
computers-on-a-chip,  each  mounted  in  separate  or  stacked  chip 
carriers  mounted  on  a reflux  soldered  ceramic  board  linked 
with  the  parent  companies  bus  system  by  1985.  Motorola,  Intel, 
and  Texas  Instruments  are  the  strongest  entrants  in  this  seg- 
ment of  the  semiconductor  industry. 
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The  ASN  RD/XL  in  mid  1978  accepts  with  some  important 
modifications,  the  mid  and  long  term  strategy  indicated  in 
their  memo  of  30  March  1977.  Influenced  by  the  rapidity  with 
which  heavy  industrial  process  control  is  being  implemented 
by  single  chip  computers,  particularly  in  the  automobile 
industry,  and  also  by  the  success  of  the  PDP11M/LSI 11M,  the 
strategy  endorses  the  idea  of  a military  computer  architecture 
family  with  the  PDP11/LSI11  family  as  the  leading  candidates 
but  reserves  comment  on  the  ultimate  long  term  standard  to 
review  the  progress  of  the  single  chip  computer. 

Because  they  are  already  established,  the  UYK7  and  20  pro- 
grams receive  endorsement  for  continuation  as  the  interim 
standard  for  shipboard  application.  However,  when  the  F18 
program  and  the  AV8B  Harrier  do  not  receive  the  production  go 
ahead  decision  for  Fiscal  79  in  favor  of  increased  emphasis  on 
VSTOL  (with  the  A7/A4M/F14  filling  the  gap) , the  AYK14  loses 
the  substantial  part  of  its  base  as  the  airborne  standard  com- 
puter. Because  of  this,  two  other  major  AYK14  programs,  the 
P3C  Update  III  and  the  LAMPS  Mk  III  program,  are  in  doubt  as 
to  how  to  proceed.  The  P3C  update  does  not  happen  with  the 
AYK14  networked  to  the  central  computer  but  rather  with  a 
redesign  of  its  software,  particularly  the  Omega  subroutine. 

A complete  internal  overhaul  of  the  computing  system  based  on 
a distributed  network  of  elements  of  the  military  computer 
family  (when  selected)  is  projected  as  the  ultimate  solution. 
The  LAMPS  Mk  III  project,  further  along,  uses  the  AYKl4's 
already  contracted  for  at  a projected  base  of  about  300.  A 
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further  evaluation  point  relevant  to  the  AYK14  for  the  Naval 
Air  Systems  Command  of  the  ASN  RD/IL  memo  is  not  needed 
because  of  its  demise  in  the  F/A-18,  AV8B , P3C  decisions. 

The  mid  1979  RFP  for  VSTOL  therefore  is  developed  without 
reference  to  the  AYK14  and  only  refers  to  the  desire  to 
adhere  to  elements  of  the  ultimate  military  computer  family 
when  selected. 

The  structure  of  the  Navy  shipbuilding  program  is  coales- 
ing with  the  President's  budget  for  FY80,  rmving  toward  a 600 
ship  Navy.  Seventy  ships  will  be  capable  of  landing  and 
launching  VSTOL  aircraft.  All  will  be  capable  of  multi- 
mission support  and  organizational  and  intermediate  mainten- 
ance with  the  exception  of  the  CGSN  strike  cruiser  and  the 
DD963H.  These  two  will  be  capable  of  single-mission  support 
and  organizational  level  maintenance.  The  return  from  the 
avionics  conceptual  studies  and  tracking  of  the  Automatic  Test 
Equipment  Tri-Service  Project  show  that  advances  in  built-in- 
test  (BIT)  will  mean  preventive  maintenance  will  consist  of 
monitoring  BIT  program  indicators  and  corrective  maintenance 
can  consist  of  faulty  module  (SEM2A  size)  replacement  at  the 
organizational  level  or  line  replaceable  unit  (LRU)  removal 
of  the  ATR  size,  with  module  discard  taking  place  at  either 
organizational  or  intermediate  level. 

The  demise  of  the  F/A-18,  and  AV8B  Harrier  in  favor  of 
VSTOL  and  hence  the  reduced  base  of  the  AYKl 4 , plus  the  rise 
in  use  of  the  PDPllM/LSIllM  family  has  not  stemmed  by  mid 
1979  the  proliferation  of  other  microprocessing/microcomputing 
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devices  in  embedded  use  in  mission  oriented  and  sensor 
equipment. 

The  automobile  industry  has  from  the  fall  of  1977  to  mid 
1979  followed  a decisive  path  in  their  use  and  standardiza- 
tion of  microprocessors /microcomputing  devices.  After  an 
initial  time  of  competition  between  model  divisions  they  have 
responded  to  the  rapid  pace  of  integration  of  the  entire  com- 
puter to  the  chip  level  so  that  by  mid  1979  they  have  devel- 
oped form,  fit,  and  function  standards  bused  on  word  length, 
multiplexed  bus  type  and  instruction  set  Ly  corporation , wit  h R>rd 
choosing  the  Motorola  6800  family,  GM  the  Intel  8048  family 
and  Chrysler  the  TI  9940  family.  The  result  is  that  by  mid 
1979  distributed  processing  demonstrators  have  been  established 
with  production  units  numbering  in  the  millions  to  go  into  the 
1981  model  year  cars. 

The  NASA  RFF  of  late  1977  is  awarded  in  April  1978.  By 
late  1980,  early  1981,  tine  results  are  in,  the  TI  9940  based 
family  being  chosen  as  the  general  aviation  standard  family 
because  of  its  16-bit  word  length,  wide  usage  base  by  Chrysler 
in  distributed  fashion,  and  second  sourcing. 

The  VSTOL  validation  and  concept  definition  advanced 
development  proceeds  with  the  NASA  demonstration  as  an  input 
to  the  core  avionics  development,  particularly  in  the  multi- 
function display  area.  The  Navy  lab  structure  is  awarded  the 
concept  definition  and  advanced  development  phase  vice  an 
avionics  shop  or  the  airframe  manufacturer.  The  two  leading 


194 


candidates  costed  from  this  scenario  are  the  PDP1 1M/LS1 1 1M  in 
a heterogeneous  network  and  either  one  of  the  Intel,  Motorola, 
or  Texas  Instruments  single  chip  computer  families  in  a com- 
pletely homogeneous  network.  (The  T1  9940  family  will  bo 
chosen  for  illustration  purposes  since  it  is  also  hypothesized 
to  be  chosen  by  NASA  for  general  aviation.) 
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E.  COSTING  RESULTS 


Illustrative  costing  results  are  generated  from  the  two 
scenarios  for  each  of  their  three  cases — neutral  (most  likely) , 
slightly  optimistic,  and  slightly  pessimistic--for  both  the 
heterogeneous  and  homogeneous  computer  architecture  alter- 
natives. Two  equations  are  used  in  conjunction  with  the  narra- 
tive of  the  scenarios  to  determine  several  of  the  cost  numbers. 
The  first  equation  is  the  production  learning  or  industry  ex- 
perience curve  formulation. 

y = axb  ( 9-1  ) 

b = loo  S/log  2 ( 9-2  ) 


th 


where 

y = unit  cost  (price)  of  the  x—  unit 
a = cost  (price)  of  the  initial  accumulated  quantity,  A 
x = total  accumulated  quantity 

S = % of  previous  cost  (price)  that  cost  (price)  drops 
to  when  accumulated  quantity  doubles. 

The  second  equation  is  the  compounded  annual  rate  of  growth 
equation  used  often  in  the  business  world  to  describe  alterna- 
tive future  product  sales  outcomes. 


mA  = A ( 1+g ) 


( 9-3) 


where 


m = multiple  of  the  initial  accumulated  quantity 
A * initial  accumulated  quantity  in  units 
g = annual  growth  rate  in  percent  expressed  as  a decimal 
T = years  to  attain  the  multiple  of  accumulated  quantity 


desired. 


To  bo  useful,  these  equations  need  an  estimate  for  each 
of  the  parameters.  These  estimates  were  generated  for  this 
report  by  the  process  of  constructing  the  neutral,  slightly 
optimistic,  and  slightly  pessimistic  cases  of  each  of  the  two 
scenarios.  Figures  (9-3)  and  (9-4  ) show  composite,  graphic 
representations  of  the  use  of  these  equations  with  representa- 
tive values  from  this  report. 

The  generic  work  breakdown  structure  (WBS)  of  the  Tri- 
Service  Tactical  Communications  office  (TR1-TAC)  Fort  Monmouth, 
New  Jersey,  was  used  to  develop  life  cycle  cost  elements  for 
the  costing  effort  (Figure  ( 9-5)).  The  method  used  to  deter- 
mine whether  a cost  element  was  applicable  was  to  first  assume 
that  the  WBS  applies  to  the  entire  VSTOL  aircraft.  Then, 
following  the  logic  flow  of  Figure  ( 9-6)  from  reference  (9-3), 
a list  of  significant,  applicable  cost  elements  for  each  of 
the  alternative  architectures  under  the  three  cases  of  the  two 
scenarios  were  considered  for  their  contribution  to  the  VSTOL. 
Preliminary  costing  results  are  pictured  in  Figure  ( 9-7). 

Equations  ( 9-1)  and  ( 9-3)  were  used  to  determine  acqui- 
sition costs  for  each  basic  computing  unit  of  the  alternative 
architectures.  Annual  rates  of  product  or  device  growth  of  use 
were  chosen  as  30%  for  the  slightly  pessimistic  case,  50%  for 
the  most  likely  (neutral)  case,  and  100%  for  the  slightly  op- 
timistic case.  Selected  examples  of  why  these  rates  were 
chosen  and  how  the  initial  accumulated  quantity  and  their  unit 
acquisition  costs  were  determined  and  led  to  the  values  in  1966, 
the  hypothesized  year  of  comparison,  are  outlined  below.  All 


TION  COST  WITH  85%  EXPERIENCE  CURVE. 


ACCUMULATED  QUANTITY  AS  A FUNCTION  OF  INITIAL  ACCUMULATED  QUANTITY  (A) 


PESSIMISTIC  NEUTRAL  OPTIMISTIC 


I . 0 Research  and  'hac  lopiiitMH 

l.l  Concent  »>'d  Vaiidut’<>n 

1.1.1  t '!'  I rue  tor 


1 . 2 Fu ’ 


1.2  Go\ o rnmon  t 


vv  e lopmen  t ( FSD ) 


2.1  Con * rac  tor 

1 . 2 . i . 1 Program  Management 

1.2. 1.2  Engineering 

1.2.1 .3  Fa tu cut  ion 

1 . 2 . 1 . -1  Contractor  Development  Tests  (CDT) 

1.2. 1.5  Test  Support 

1.2. 1.0  Producibil  lty  Engineering  and  Planning  tPi.! 
: .2.1.7  Data 

1 .2.  1.7.1  Engineering  Data 

1 . 2 . 1 . 7 . 2  Support  Da tn 
' 2.1.7. 3 Managemen t Da ’ a 
. 2.1.7. d Technical  Orders  and  Manuals 
1,2. ’.8  Peculiar  Support  and  Test  Equipment 

1 . 2 . 1 . 9 Other 

1.2.1.10  General  and  Administrative 

1.2.1.11  Fee 

2.2  Government 

1.2.2. 1 Program  Management 

1.2. 2. 2 Test  Site  Activation 

1.2. 2. 3 Government  Tests  tPTE/lOTE) 

2 . 4 Government  Furnished  Equipment  (GFE) 
l!Y.  3?  5 Other 


COST  ELEMENT  STRUCTURE 


Source:  TRI-TAC 


Figure  9-5" 


2.0  Investment.  (Non-Recurring) 

2 . 1  Contractor 

2.1.1  Program  Management 

2.1.2  Produe.bi 1 tty  Engineering  and  Planning  (PEP) 

2.1.3  Initial  Production  Facilities  (IPF) 

2. 1.3.1  Production  Engineering 

2 . 1 . 3 . 2 Tool i ng 

2. 1.3. 3 Industrial  Facilities 

2.1.3. 4 Manufacturing  Support  Equipment 

2.1.4  Techniea*  Support 

2.1.5  Initial  Spares  and  Repair  Parts 

2.1.6  Initial  Training 

2.1.6. 1 Training  Facilities 

2. 1.6. 2 Training  Devices  and  Equipment 

2. 1.6. 3 Initial  Student  Training 

2. 1.6.3. 1 Operator  Training 

2. 1.6. 3. 2 Maintenance  Training 

2. 1.6. 3. 3 Instructor  Training 

2.1.7  Data 

2. 1.7.1  Engineering  Data 

2. 1.7. 2 Support  Data 

2. 1.7.3  Management  Data 

2. 1.7. 4 Technical  Orders  and  Manuals 

2.1.8  Leaseholds 

2.1.9  Common  Support  Equipment 

2.1.10  Peculiar  Support  and  Test  Equipment 

2.1.11  Other  Non-Recurring  Costs 

2.1.12  General  and  Administrative 

2.1.13  Fee  or  Profit 


Figure  (continued! 

201 


2.2  Government  ( Non-Hoeu rr i ng ) 

2.2.1  Program  Management 

2.2.2  Initial  Training 

2. 2. 2.1  Training  Facilities 

2. 2. 2. 2 Training  Devices  and  Equipment 

2. 2. 2. 3 Initial  Student  Training 

2. 2. 2. 3.1  Operator  Training 

2. 2. 2. 3. 2 Maintenance  Training 

2. 2. 2. 3. 3 Instructor  Training 

2.2. ?  Production  Acceptance  Test  and  Evaluation  (PATE) 

2.2. *.  Operational  Test  and  Evalua i .on  (OTE) 

2.2.5  Test  Site  Activation 

2.2.6  Government  Furnished  Equipment  (GFE) 

2.2.7  Other  Non-Recurring  Investment  Costs 


Figure  9-.f 


(continued^ 


I 

I 


3 0 investment  v Recurring) 

3.1  Contractor 

3.1.1  Manu  f ac  tun  ng 

3.1.2  Produc t l on  Ma tonal 

3.1.2. 1 Purchased  Equipment  and  Parts 

3 . 1 . 2 . 2 Suocon t rao t cd  1 1 oms 

3. 1.2. 3 Other  Material 

3.1.3  Sustaining  Engineering 

3.1.  -I  Quality  Control  and  Inspection 

3.1.5  Packaging  ana  Transport  a t ion 

3.1.0  Opera t ion.il/Si  te  Activation 

3. 1.6.1  Site  Construction 

3. 1.6. 2 Si te/Sh ip/ Vehicle  Conversion 

3. 1.6. 3 Assembly,  Installation  and  Checkout 

3.1.7  Other  Recurring  Investment  Costs 

3.1.8  General  and  Administrative  Costs 

3.1.0  Fee  or  Pro t"  1 1 

3.2  Government  (Recurring) 

3.2.1  Quality  Control  and  Inspection 

3.2.2  Sustaining  Engineering 

3.2.3  Transportation 

3. 2.  -I  Operat lonal/Sito  Activation 

3. 2.  <1.1  Site  Construction 

3. 2.  -1.2  Site/Ship/Vehieio  Con*  ersion 

3. 2.  -1.3  Assembly.  I nst  a 1 la  . ic.i  and  Checkout 

3. 2.3  Technical  Orders  and  Manuals 

3.2.6  Government  Furnished  hatenal 

3.2.7  Other  Recurring  Cost 


Figure  9-*»  (cent  inued) 
203 


- 


1.0  Operating  and  Support  Costs  (0Kd>) 

•1.1  Operations 

4.1.1  Electrical  Power 

4.1.2  Special  Materials 

4.1.3  Operator  Personnel 

4.1.4  Operational  Facilities 

4.1.5  Equipment  Leaseholds 

4.1.6  Other  Operations  Costs 

4.2  Logistic  Support 

4.2.1  Maintenance 

4.2. 1.1  Personnel 

4.2.1.  1.1  Organizational  Maintenance  Personne1 

4. 2. 1.1. 2 Intermediate  Maintenance  Personnel 

4.2. 1.1.3  Depot  Maintenance  Personnel 

4. 2. 1.2  Maintenance  Facilities 

4. 2. 1.3  Support  Equipment  Maintenance 

4.2. 1.4  Contractor  Services 

4.2.2  Supply 

4.2.  . 1 Personne  1 

4. 2. 2.1. 1 Organizational  Supply  Personnel 

4.2.2. 1.2  Intermediate  Supply  Personnel 

4.2.2. 1.3  Depot  Supply  Personnel 

4. 2. 2. 2 Supply  Facilities 

4. 2. 2. 3 Spare  Parts  and  Repair  Material 

4. 2. 2. 4 Inventory  Administration 

4. 2. 2. 4.1  Inventory  Management 

4. 2. 2. 4. 2 Inventory  Holding 

4. 2. 2. 5 '"ranspor  tat  ion  and  Packaging 

4.2.3  Other  Logistic  Support  Costs 


r • gure 
204 


9-S 


(continued ) 


YES 


COST  ELEMENT  SELECTION  DECISION  PROCESS 
Figure  9-6 


PRELIMINARY  RESULTS  FOR  SELECTED  COST  ELEMENTS  (MILLIONS  OF  FY  77$,  DISCOUNTED  ZERO  PERCENT) 


dollars  are  expressed  in  current  dollars.  Inflation,  the  rise 
in  the  general  price  level,  is  assumed  to  affect  all  inputs 
equally.  Discounting  was  done  using  a zero  percent  rate.  Us- 
ing the  standard  DOD  10%  figure  would  only  make  the  homogeneous 
case  even  more  cost-effective. 

To  determine  the  unit  acquisition  cost  of  the  naval  air- 
borne standard  computers  of  the  heterogeneous  alternative 
in  1985,  the  number  of  these  computers  procured  for  naval  air- 
borne systems  by  1985  as  a first  cut  was  chosen  to  be  about 
6,000  based  on  the  projections  of  reference  (9-1).  Interviews 
with  members  of  the  military  computer  industry  indicate  that 
their  industry  average  experience  curve  is  85%,  i.e.  as  accum- 
ulated quantity  doubles,  acquisition  cost  to  the  user  comes 
down  15%.  Currently  the  annual  rate  of  growth  in  units  sold 
of  the  military  computer  industry  is  conservatively  (slightly 
pessimistically)  projected  at  30%  annually  (9-4). Using  an 
initial  accumulated  quantity  of  500  for  the  naval  airborne 
standard  (from  unofficial  procurement  plans  and  industry  inter- 
view) , a 30%  and  a 50%  annual  growth  rate  bracket  the  afore- 
mentioned 6,000  unit  base  projected  for  1985. 

Three  things  are  worthy  of  note  at  this  point  in  the  devel- 
opment of  these  and  subsequent  figures.  First,  the  industry 
experience  curve  can  be  interpreted  in  a negotiated  procurement 
environment  as  a production  (labor)  cost  learning  curve.  The 
naval  airborne  standard  computer  would  be  in  production  run  on 
a fixed  price  type  of  contract  for  costing  purposes  in  the 
time  frame  of  this  report.  Second,  the  curve  represents  the 


207 


unit  learning  (experience)  curve.  The  cumulative  average 
learning  curve  would  lie  slightly  above  the  unit  learning  curve, 
generating  an  average  unit  acquisition  cost  for  a purchase  in 
quantity  slightly  above  the  unit  cost  curve. 

Finally,  note  that  sustaining  engineering  is 
included  as  one  of  the  recurring  manufacturing  costs  that  leads 
to  the  acquisition  cost  to  the  user  by  the  computer  industry. 

The  meaning  of  this  is  that  new  models  of  the  naval  airborne 
standard  would  continue  to  incorporate  innovations  in  LSI 
technology,  bubble  memory,  etc.,  as  the  costs  of  the  naval  air- 
borne standard  continued  to  come  down. 

Returning  to  how  the  total  of  the  unit  acquisition  costs 
were  developed,  the  number  of  VSTOL  aircraft  in  the  buy  was 
estimated  at  1,000  from  the  force  structure  analysis  referred 
to  earlier.  The  heterogeneous  architecture  calls  for  two 
naval  airborne  standard  computer  units  per  aircraft  for  the 
core  avionics.  2,000  units  would  be  procured  at  unit  acqui- 
sition cost  of  $30,000  for  a total  of  $60,000,000  for  the  VSTOL 

* 

fleet . 

The  airborne  standard  scenario  has  hypothesized  that  the 
Naval  Air  Systems  Command  would  undertake  the  development  of  an 
airborne  family  microprocessor,  not  a microcomputer  since  the 
scenario  assumed  integration  of  circuitry  only  to  the  computer 
building  blocks  of  processor,  memory,  input/output,  and  timing 
circuits  at  the  point  in  time  a development  decision  was  hy- 
pothesized. The  development  program  is  assumed  undertaken  be- 
ginning in  mid  1979  with  the  reevaluation  point  of  the  f 
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ASN(KD/rii)  memo  referred  to  in  the  scenario,  and  completed  in 
1930.  Rased  on  a nonrecurring  development,  cost  of  $150  per 
gate  and  an  equivalent  gate  count  of  10,000  for  a single 

or  a few  chip  LSI  processor  made  from  the  military  family  of 
LSI  chips  the  nonrecurring  development  cost  would  be  about 

$1,500,000.  Note  that  this  would  be  a sunk  cost  with  respect 
to  the  VSTOL  program.  The  initial  accumulated  quantity  and 
acquisition  cost  was  determined  in  the  following  way.  Pricing 
two  existing  military  microprocessors,  the  LSI11M  and  the  AYK30, 
their  single  quantity  price  is  about  $2,500.  In  lots  of  500 
or  more  there  is  a 15%  reduction  in  price  which  would  make  the 
in  quantity  unit  price  about  $2,125.  The  growth  rates  for  these 
two  military  microprocessors  were  estimated  for  up  to  the  next 
couple  of  years  at  100%  annually  from  interviews.  The  price  in 
quantity  of  each  of  these  military  microprocessors  would  be 
about  $1,500  by  1930,  using  equations  ( 9-1)  and  (9-3  ),  an 
85%  curve  and  the  information  above.  This  is  assumed  used  as 
a design-to-cost  figure  by  Nav  Air  in  the  airborne  standard 
microprocessor  development.  Based  on  the  $1,500,000  nonrecur- 
ring development  cost  and  the  $1,500  dcsign-to-cost  figure, 
the  developer  would  need  at  least  an  initial  quantity  order  of 
1,000  to  at  least  cover  his  nonrecurring  cost  of  development 
and  make  him  competitive  with  the  LSI11M/AYK30  products. 

This  was  chosen  as  the  initial  accumulated  experience  quantity 
available  in  1980  after  a year's  development  effort.  A modest 
projection  of  the  annual  growth  rate  of  microproccssor/mi cro- 
computer  devices  annually  as  an  industry  is  projected  at  50% 
for  the  next  several  years  (9-6).  This  growth  rate  was  assumed 
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for  the  naval  airborne  standard  microprocessor  in  airborne 
systems  as  the  neutral  (most  likely)  case  to  beqin  in  1980 
when  the  device  would  be  ready. 

Based  on  the  hypothesized  1,000  plane  VSTOL  buy,  and  10 
of  these  airborne  standard  microprocessor  devices  per  plane 
in  the  heterogeneous  architecture  alternative,  a unit  acquisi- 
tion cost  of  about  $850  was  estimated  by  1985.  Since  each 
naval  airborne  standard  microprocessor  would  need  memory 
(16K  words),  parallel  and  serial  bus  interfacing,  and  a float- 
ing point  package  to  accomplish  its  task  even  in  embedded  use, 
these  would  have  to  be  costed  into  the  basic  processing  unit 
since  a microprocessor  is  not  capable  of  doing  anything  without 
these  other  items.  Using  the  LSI11M,  AYK30,  ROLfl  Corporation 
and  other  price  lists  for  these  components,  costing  by  analogy 
was  done  with  a multiplicative  cost  factor  of  about  4 being 
surprisingly  consistent  across  the  various  companies.  This 
would  mean  for  the  neutral  case,  for  example,  about  $3,400  for 
each  microcomputing  unit  at  the  front  end  of  an  avionics  sub- 
system . 

Two  other  costs  need  to  be  considered.  The  first  is  the 
nonrecurring  cost  of  programming  Automatic  Test  Equipment  (ATE) 
like  that  in  the  Versatile  Avionics  Shop  Testor  (VAST)  for  the 
printed  circuit  cards  that  would  be  in  each  piece  of  computer 
equipment.  Although  a standard  computer  is  already  in  exis- 
tence, each  application  requires  a new  test  program  for  the 
ATE.  The  standard  airborne  computer  has  on  the  average  10 
boards,  each  assumed  "complex"  under  the  description  of  refer- 
ence (9-7). A 90%  comprehensive  median  (neutral)  cost  of  ATE 
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programming  would  bo  $15,000  per  board,  a total  of  $150,000 
for  the  unit  in  the  neutral  case.  The  airborne  standard  micro- 
processor plus  the  equipment,  to  make  it  a microcomputer  is 
assumed  to  be  six  boards  in  a Navy  Standard  Electronic  Module 
2A  (SEM2A)  product.  At  $1,400  per  airborne  standard  micro- 
computer of  six  boards  that  is  about  $b00  per  board.  Each 
board  was  assumed  moderate  in  complexity  under  the  description 
of  reference  (9-7).  At  904  comprehensiveness,  median  (neutral) 
cost  for  ATE  programming  of  $5,000  a board  would  be  a total  of 
$30,000  for  the  product. 

The  last  cost  reviewed  at  this  point  is  a recurring  in- 
vestment cost,  the  VSTOL  flyaway  cost  attributed  to  the  comput- 
ing system  weight.  Reference  (9-5) relates  that  every  pound  of 
operational  systems  weight  contributes  6-0  lbs.  to  airframe, 
fuel  system,  and  other  supporting  systems  weight,  and  that  a 
modern  fighter  aircraft  costs  out  at  $500  per  pound  of  flyaway 
costs.  This  concept  applied  to  the  50  pounds  (2  units  at 
25  lbs.  each)  of  the  standard  units  versus  the  2-4  lbs. 

of  the  homogeneous  computing  module  makes  for  an  order  of  magni- 
tude differential  in  the  flyaway  costs  attributable  to  the 
respective  computer  architecture  alternatives. 

The  operating  and  support  costs  for  both  the  heterogeneous 
and  homogeneous  alternatives  were  generated  using  the  TRI-TAC 
Life  Cycle  Cost  Model,  and  the  D-K  Dynamics  Navy  Billet  Cost 
Model.  The  parameters  of  mean-time-between-fai lure  (MTBF)  and 
mean-time-to-repair  (MTTR)  were  taken  from  existing  data  on 
comparable  units  for  the  airborne  and  CFA  standard  computers. 

The  values  were  2,200  hours  MTBF  with  20  minutes  MTTR  at  the 
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organizational  level  of  maintenance  and  two  hours  MTTR  at 
the  intermediate  level  of  maintenance.  For  the  airborne 
standard  microprocessor,  and  for  the  homogeneous  microcom- 
puter the  most  likely,  slightly  optimistic  and  slightly  pes- 
simistic case  idea  was  used  since  field  reliability  data  is 
not  mature  enough.  The  values  chosen  were  2 times,  10  times, 
and  . 5 times  the  MTBF  of  the  airborne  and  CFA  standard  comput- 
ers. A figure  of  about  25,000  hours  for  the  AYK30,  LSIllM, 
and  TI9900  demonstrated  in  a simulated  field  environment  is  the 
figure  developed  by  interview.  The  same  MTTR's  were  used  through- 
out. 

The  costing  in  the  CFA  scenario  for  the  heterogeneous 
alternative  was  also  based  on  equations  (9-1)  and  (9-3) . The 
PDP11/34M  and  LSIllM  were  used  as  representative.  The  number 
of  CFA  units  in  use  by  1985  was  generated  by  starting  with 
annual  military  computer  industry  sales  employing  LSI  tech- 
nology being  conservatively  (slightly  pessimistically)  esti- 
mated at  $100,000,000  for  1977  and  $250,000,000  by  1981  (9-4) 

This  would  be  about  a 30%  growth  rate.  Reference  (9-4)  and 
interviews  indicate  an  initial  acquisition  cost  of  about  $25,000 
for  a 1/2  ATR,  16K  work  memory  PDP11/34M  and  that  Norden 
conservatively  expects  to  grow  to  about  $50,000,000  in  sales 
annually  within  five  years.  Coupled  with  the  initial  unit 
acquisition  cost  of  about  $25,000,  an  initial  experience  base 
of  500  was  considered  representative.  This  yields  about  a 
$12,500,000  nonrecurring  development  cost  if  the  first  run 
amortizes  this  cost.  Although  not  directly  available,  this 
development  cost  figure  is  representative.  With  an  85%  industry 
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experience  (learninq)  curve  the  averaqo  acquisition  cost  Tor 
the  CFA  unit  for  the  VSTOL  core  avionics  of  the  1/2  ATR  size 
would  be  about  $15,000  in  the  slightly  pessimistic  case  by  1985. 
With  two  of  these  units  per  aircraft  and  a 1,000  plane  buy, 
the  acquisition  cost  would  be  about  $30,000,000  for  these  core 
units.  The  front  end  processing  units  would  be  as  indicated  in 
the  airborne  standard  scenario  with  the  exception  that  the 
factor  of  four  would  not  be  applied  because  of  the  assumption 
under  the  CFA  scenario  that  the  direction  of  integration  is  to 
more  rapidly  bring  all  the  building  blocks  of  a microcomputer 
into  one  LSI  chip. 

The  costs  of  ATE  programming,  and  flyaway  cost  attributable 
to  the  computing  units  were  computed  as  in  the  airborne  stan- 
dard scenario. 

No  software  development  and  support  tool  costs  were  costed 
to  either  scenario’s  heterogeneous  alternatives.  This  is  best 
casing  of  these  alternatives  since  interviews  have  shown  that 
in  many  projects  these  tools  aren't  used  or  require  modification 
to  suit  the  input/output  structure  of  the  particular  application. 

The  VSTOL  Operational  Flight  Program  development  and 
maintenance  costs  would  be  a differential  cost  element.  It  is 
computed  using  the  technique  outlined  in  the  generalization  of 
cost  issues  section  of  this  report. 

The  homogeneous  equipment  acquisition  cost  is  computed 
for  each  scenario  as  follows.  In  the  airborne  standard  the 
architecture  would  consist  of  24  single  chip  microcomputers  in 
the  core  in  two  SEM2A  sized  modules,  and  20  single  chip  micro- 
computers embedded  as  front  end  processors  in  the  avionics 


sub-system,  ten  boards  of  two  microcomputer  chips  to  a board. 

The  airborne  standard  scenario  hypothesises  that  integration 
of  computer  building  blocks  to  a single  chip  will  not  be  as 
rapid  in  terms  of  memory  size,  processing  speed,  and  input/out- 
put as  in  the  CFA  standard  scenario.  For  the  CFA  scenario, 
integration  to  single  chip  computers  progresses  at  a faster 
pace  so  that  only  12  single  chip  microcomputers  in  one  SEM2A 
sized  module  is  needed  in  the  core,  with  ten  10  boards  of  two 
microcomputers  each  as  front  end  processing  units.  These  num- 
bers are  representative  in  view  of  the  technical  information  of 
this  report. 

The  cost  per  microcomputer  chip  in  either  alternative  was 
estimated  for  the  most  likely  case  of  each  scenario  to  be  $5 
by  1985.  This  was  obtained  as  follows.  References  (9-6,  9-8)  and 
interviews  were  used  to  obtain  and  check  dollar  sales  volumes 
for  industrial  LSI  microprocessor/niicrocomputer  devices.  The 
unit  prices  attached  to  each  dollar  sales  volume  to  obtain  a 
figure  for  quantity  produced  in  each  year  is  the  Intel  8080A 
unit  price  for  those  periods  since  it  was  the  industry  price 


leader . 

1974 

$22,000,000 

$500 

each 

^ 50,000 

units 

1975 

50,000,000 

$100 

each 

* 500,000 

units 

1976 

150,000,000 

(3 

$ 25 

each 

6,000,000 

units 

Admittedly,  this  is  a rough  way  to  obtain  those  figures; 
however,  they  do  check  with  interview  sources  close  enough  to 
be  representative.  Available  volume  information  in  units  sold 
of  microprocessor/microcomputer  chip  devices  is  unreliable 
since  these  numbers  are  proprietary  information.  1^76  is 
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chosen  as  the  base  year  of  experience.  Reference  (9-6)  predicts 
an  annual  industry  growth  rate  of  50*  for  the  next  several 
years.  This  was  taken  as  the  neutral  case.  The  industry 
experience  curve  is  well  known  to  be  73%,  i.e.  as  industry 
accumulated  quantity  doubles,  cost  and  price  falls  by  27%. 

Using  the  chosen  initial  experience  accumulation  of  6,000,000, 
the  price  at  that  quantity  of  $25,  and  the  neutral  annual 
growth  rate  of  50%,  equations  (9-1  ) and  (9-3  ) yield  the  $5 
device  price  by  1985.  This  figure  checked  with  Delphi  ques- 
tionnaires and  other  forms  of  interview.  It  also  falls  in  the 
range  of  total  annual  industry  sales  volume  of  $500,000,000  to 
$1,000,000,000  predicted  from,  references  (9-6,  9-8)  for  these 
devices.  A final  way  in  which  the  feasibility  of  such  mas- 
sive volume  checks  out,  at  least  in  an  order  of  magnitude  sense, 
is  to  consider  the  possible  types  of  applications  for  these 
devices.  Reference  (9-6)quotes  that  of  some  25,000  potential 
types  of  applications  considered  within  the  realm  of  single 
chip  microcomputer  process  control,  only  10%  of  them  are 
currently  in  active  design.  Applications  range  from  automo- 
biles (10  million  vehicles  annually  with  2-3  microcomputers 
per  vehicle  being  the  industry  strategy  to  meet  the  emission 
and  mpg  standards  of  the  early  1980's),  40  million  appliances 
annually  (microwave  ovens,  washer-dryers,  TV's,  etc.),  point- 
of-sale  terminals,  precision  measurement  instruments,  to  arcade 
games,  and  children’s  toys  (into  the  100's  of  millions  annually). 
With  automobiles  and  appliances  accounting  for  nearly  100 
million  devices  annually,  it  is  reasonable  to  see  the  other 
applications  accounting  for  200-300  million  devices  annually 
by  1985  as  a neutral  case. 


These  chips  must  still  be  placed  into  a system  or  product. 
Using  the  SEM2A  size  module  with  two  chips  per  board  and  the 
reflux  solder  on  ceramic  technique  described  earlier,  an  es- 
timate of  nonrecurring  development  costs  for  such  a product  is 
about  $1 » SCO , 000  based  on  industry  interviews.  Acquisition 
costs  for  such  a product  were  obtained  from  interviews,  liter- 
ature (9-5)  , and  checked  against  available  price  lists.  The 
results  indicate  that  a factor  of  about  2 . 5 times  the  sum  ot 
the  acquisition  cost  of  the  LSI  chips  in  the  product  can  be 
used  to  account  for  the  contribution  of  the  printed  circuit 
boards,  interconnects,  chassis,  and  power.  Another  factor  of 
2-3  accounts  for  the  cost  of  making  the  product  suitable  for  a 
severe  environment.  While  seemingly  rough  factors,  they  cheek 
out  surprisingly  consistently  across  products  in  the  minicom- 
puter and  microcomputer  range  both  in  terms  of  available  data 
and  industry  interview. 

Using  these  two  factors  and  the  neutral  case  of  50 * 
annual  growth  for  microcomputing  devices  which  yields  $5 
devices,  a SEM2A  module  of  six  boards  with  two  devices  per 
board  would  have  an  acquisition  cost  of  $450.  Two  modules  would 
be  needed  in  the  core  of  the  homogeneous  architecture  alterna- 
tive to  be  equivalent  in  performance  with  the  airborne  stan- 
dard heterogeneous  architecture  alternative  under  the  assump- 
tions of  that  scenario.  One  module  would  be  needed  in  the  core 
of  the  homogeneous  architecture  alternative  to  be  equivalent 
in  performance  with  the  CFA  standard  heterogeneous  architecture 
alternative  under  the  assumptions  of  th.it  scenario. 


This  concludes  the  discussion  of  how  the  costing  results 
were  obtained.  While  not  every  case  of  the  two  scenarios  was 
detailed,  hopefully  the  reader  qainod  enough  to  understand  how 
the  costing  results  of  Figure  (9-7)were  obtained.  A narrative 
summary  of  these  results  would  be  put  as  follows.  For  air- 
borne applications,  the  rate  of  technological  change  and  growth 
of  general  use  of  LSI  microcomputing  devices  is  great  enough 
to  offset  any  cost  advantages  of  standardization  of  computers 
and  software  development  and  support  tools  even  of  the  form, 
fit,  and  function  type.  The  three  significant  areas  of  cost 
that  manifest  this  are  the  acquisition  cost,  the  operating  and 
support  costs,  and  the  aircraft  flyaway  cost  attributable  to 
the  computers.  Even  without  the  flyaway  cost  eonsideied,  the 
homogeneous  case  is  the  cost-effective  alternative  under  both 
scenarios  and  all  cases.  If  these  results  hinged  on  one  con- 
dition, it  would  be  the  continued  understanding  of  distributed 
computing  and  the  continued  development  of  the  software  to 
effect  it. 
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Appendix  A. 


GENERALIZATION  OP  COST  ISSUES 
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This  section  presents  for  the  reader  a narrative  tutorial 
on  the  cost  issues  involved  in  systems  engineering  with  LSI 
based  circuitry,  particularly  microcomputing  devices.  A few 
controversial  things  should  be  immediately  pointed  out  for 
the  initiated  reader  as  being  conjectured  by  this  report,  and 
supported  elsewhere.  The  first  is  that  while  useful  to  an 
extent,  cost  per  gate  or  cost  per  bit  may  no  longer  be  as 
relevant  a parameter  for  systems  engineering  with  microcompu- 
ting/microprocessor devices  as  cost  per  device  plus  cost  per 
interconnect  of  devices (2-1) . Second,  the  cost  of  special 
hardening  of  a microcomputing/microprocessing  device  against 
radiation,  shock,  heat,  and  other  environmental  factors  by 
the  use  of  sapphire  substrates,  etc.,  may  be  overkill  when  its 
contribution  to  overall  aircraft  survivability  is  assessed. 

And  finally,  the  actual  cost  contribution  of  software  may  not 
be  minimized  by  adherence  to  standard  computing  devices  nor 
even  paramount  when  total  systems  engineering  costs  are  con- 
sidered (specifically  aircraft  weight  penalty  from  standard 
computing  devices  in  this  report's  analysis).  With  these 
ideas  brought  forward,  some  tutorial  cost  generalizations  will 
now  be  described. 

A.  HARDWARE 

A key  to  the  economic  aspects  of  systems  engineering  with 
LSI  circuitry  based  systems  is  in  the  associated  manufacturing 

I 

technology.  Manufacturing  technology  is  the  means  by  which 
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something  is  fabricated  by  the  producer.  Typically  any  product 
will  go  through  several  stages  of  processing  from  raw  material 
to  finished  system  with  value  added  at  each  stage.  It  is  the 
technology  which  takes  production  through  each  of  these  stages 
that  is  called  manufacturing  technology.  It  can  be  embodied 
in  the  form  of  a more  educated  or  trained  labor  force,  new 
capital  equipment  capable  of  enhanced  production,  or  an  inter- 
action of  the  two. 

Because  systems  engineering  with  LSI  circuitry  is  to  a 
great  degree  influenced  by  semiconductor  manufacturing  tech- 
nology, a simplified  version  of  the  steps  gone  through  to 
create  a microprocessor/microcomputer  based  process  control 
system  will  be  presented.  The  steps  are  annotated  with  econ- 
omic "thumb  rules,"  gained  from  personal  interviews  and  liter- 
ature search,  that  generalize  the  cost  issues  involved  in  LSI 
circuitry  systems  engineering.  All  dollars  are  expressed  in 
current  year  dollars.  The  steps  are  shown  as  sequential  but 
in  reality  may  overlap  in  time. 

The  lowest  cordon  denominator  sought  as  a measure  for  circuit 
design  of  an  LSI  device  is  the  active  element  group  (AEG);  a gate 

for  logic  units,  a bit  for  memory  units.  Measures  of  com- 
plexity and  recurring  device  manufacturing  cost  are  made 
parametrically  on  AEG  counts.  Figure  A-lis  a composite  over- 
view of  the  trends  in  device  complexity  and  recurring  manu- 
facturing cost  in  the  last  several  years  for  the  silicon 
metal  oxide  semiconductor  device  technology.  The  description 
of  the  steps  that  follow  will  develop  how  Figure A-lis 
constructed. 
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COST/ CO  UPON  ENT,  cent 


The  first  step  in  the  h'-*l  menu  fact ui  i no  process  however 


is  not  included  in  the  computations  to  obtain  figure 
This  first  step  is  the  creation  of  the  circuit  logic  design 
and  accounts  for  the  major  share  of  the  non-recurring  costs 
of  production.  In  the  case  of  an  original  design  which  works 
significantly  into  a semiconductor  manufacturer's  corporate 
strategy  (like  the  Intel  8080,  Motorola  6800,  and  Texas 
Instruments'  9900),  the  cost  of  this  creative,  labor  inten- 
sive activity  is  generally  in  the  millions  of  dollars,  and 
one  to  two  years  of  calendar  time.  For  the  8080,  6800,  and 
9900,  the  figure  was  probably  around  $5,000,000  each.  A 
reasonable,  although  large,  range  for  this  non-recurring 
cost  is  from  $100,000  to  the  few  millions.  The  large  vari- 
ance comes  from  a number  of  factors  ranging  from  corporate 
financial  structure,  and  marketing,  to  existing  design  tools. 
Separating  out  this  latter  factor  as  one  which  could  be  appli- 
cable industry  wide,  reveals  two  significant  developments 
that  have  the  potential  of  reducing  this  non-recurring  cost. 
These  are  computer-aided-design,  and  the  use  of  general  cir- 
cuit design  arrays  that  are  customized  in  the  final  masking 
and  diffusion  steps  (to  be  explained  more  fully  later).  Some 
companies  have  reported  out  in  the  trade  magazines  reduction 
in  calendar  time  for  development  of  a logic  design  to  2-3 
months  and  a reduction  in  non-recurring  cost  of  design  into 
the  tens  of  thousands  of  dollars  from  the  hundreds  of  thousands 
of  dollars.  (A  question  which  remains  unanswered  but  will  be 
addressed  later  is  if  the  non-recurring  cost  of  the  design  of 
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the  testing  procedures  for  these  custom  LSI  chips  has  been 
included  in  this  reduced  non-recurring  cost.)  Being  the 
first  step  in  the  process  and  particularly  if  tied  heavily 
into  the  corporation ' s strategic  planning,  working  out  a 
logic  design  which  later  proves  faulty,  which  has  problems 
in  production  and  testing,  and  which  has  missed  the  market, 
can  quickly  put  a source  of  LSI  circuits  into  financial 
straits.  To  a high  level  military  budget  planner,  thinking 
in  terms  of  hundreds  of  thousands  oL  dollars  or  even  a few 
millions  of  dollars  may  not  be  significant.  We  are  numbed 
by  large  numbers  almost  daily.  However,  even  a casual 
reading  of  a magazine  like  Business  Week  gives  one  an  appre- 
ciation for  how  in  a fiercely  competitive  business  like 
semiconductors,  risking  and  losing  from  a few  hundred  thou- 
sand dollars  into  the  few  millions  of  dollars  and  the  con- 
current few  months  of  time  can  set  a corporate  strategy  on 
its  head  and  leave  companies  as  biq  as  Texas  Instruments 
trying  to  overcome  the  effects  (9-6)  . 

After  the  logic  design  has  been  worked  out,  the  next  step 
is  drafting  and  documenting  the  design.  This  generally  takes 
from  2-3  man-months.  If  computer-aided-design  was  used,  this 
step  can  be  a fallout  of  the  actual  logic  design  process. 

The  next  part  of  the  process  entails  growing  a very  pure 
sausage-shaped  silicon  ingot. 
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The  silicon  raw  material  is  a miniscule  part  of  the  cost. 
Other  materials  used  are  silicon-on-sapphire  (SOS)  (obviously 


i 


i 


a 


E 


more  expensive  in  terms  of  raw  material),  and  most  recently 
the  use  of  GR-AS  illium-Arsenide. 

The  ingot  diameter  is  a crucial  number.  The  diameter 
has  grown  from  1-2  inches  to  3-4  inches,  with  5-6  inches  being 
the  leading  edge  of  the  technology.  Beyond  6 inches,  while 
possible,  creates  warping  problems  when  the  ingot  is  sliced 
into  wafers.  The  crucialness  of  increasing  the  ingot  diameter 
is  the  multiplicative  effect  it  has  on  the  number  of  chips 
that  can  be  created  in  one  process  set  up.  For  example,  the 
ratio  of  surface  area  on  a 4-inch  diameter  ingot  to  one  with 
a 3-inch  diameter  is  simply 

s4  n <j>  16 

S3  ' „ ,|>2  " 9 ' 

or  roughly  1.8  times  the  number  of  possible  chips.  Note  how- 
ever that  this  ratio  decreases  as  the  ingot  grows  successively 
larger,  another  reason  why  expanding  incrementally,  by  heavy 
capital  investment,  beyond  a 6-inch  ingot  is  considered  very 
leading  edge  technology  and  very  unlikely  in  the  future. 

The  next  manufacturing  phase  is  to  slice  the  ingot  into 
wafers,  each  about  0.03  inches  thick. 


The  wafers  are  then  sent  through  a masking  and  diffusion  pro- 
cess anywhere  from  three  to  ten  times.  This  process  entails 
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miniaturizing  and  replicating  the  circuit  design  on  the  wafer. 
A photolithographic  technique  is  used  for  masking.  As  minia- 
turization beyond  optical  resolution  levels  occurs,  an  elec- 
tron beam  technique  is  used.  Masking  basically  lays  out  the 
negative  of  the  circuit  pattern,  and  diffusion  "etches”  the 
pattern  onto  the  surface  of  the  wafer.  (The  generalized 
circuit  array  process  mentioned  earlier  etches  out  several 
clusters  of  common  circuit  elements  and  these  wafers  are  put 
"on-the-shelf . " A final  masking  and  diffusion  will  connect 
up  only  those  elements  desired  for  the  "customized"  circuit 
design  when  a user  orders  it  up.  This  customized  design 
however  must  still  undergo  testing  procedures  developed  for 
it  and  it  alone.) 

The  first,  and  most  significant  of  three  test  points  now 
occurs.  The  etched  wafer  is  inserted  into  a test  probe  where 
some  very  simple  tests  are  used  to  determine  bad  chips.  The 
industry  average  wafer  yield  is  only  about  30-40%.  For 
example,  if  a 4-inch  diameter  ingot  is  used  and  a 200  mil  x 
200  mil  (0.2  inch  x 0.2  inch)  chip  is  desired,  the  maximum 
number  of  chips  per  wafer  that  can  be  etched  is  a few  less 
than  300.  Hence,  only  about  100  are  acceptable  after  this 
check  point.  Furthermore,  that  30-40%  wafer  yield  is  the 
industry  average.  As  a new  device  is  being  produced,  wafer 
yield  may  be  as  low  as  5%  until  an  initial  experience  base 
has  accumulated.  (This  initial  base  is  estimated  at  32 
wafer  runs  or  about  10,000  "possible" chips . ) Learning  occurs 
and  the  yield  will  eventually  reach  the  30%  average,  and  for 


some  designs  and  in  sonic  companies,  wafer  yield  may  reach  as 
high  as  40-50%  for  a sustained  run  of  wafers.  However,  for 
some  logic  designs  or  for  some  companies  the  industry  average 
of  30%  wafer  yield  might  never  be  reached,  particularly  if 
the  production  run  is  not  sustained  over  time. 

After  going  through  the  test  probe  and  marking  of  the  bad 
chips,  the  wafer  is  scribed,  i.e.,  the  wafer  is  cut  up  into 
individual  chips.  The  bad  chips  are  discarded  and  the  good 
chips  are  sent  to  be  packaged.  Three  methods  are  currently 
used  to  package  the  chips.  The  oldest  method,  the  flat  pack, 
has  been  largely  replaced  by  the  most  prominent  method,  the 
dual- in-line  (DIP)  package.  The  third  method,  the  chip 
carrier,  is  the  leading  edge  packaging  technology  and  will 
be  discussed  shortly.  In  the  DIP,  the  chip  is  placed  on  a 
lead  frame  by  a worker  using  a special  machine  and  a microscope. 


The  leads  are  bonded  by  pressure  to  the  chip  and  to  the  pins. 
This  is  generally  a labor  intensive  process  and  the  cost  of 
DIP  packaging  is  considered  as  an  increasing  function  of  the 
number  of  pins  (leads  off  the  chip) , with  40  pins  being  the 
break  point  where  the  cost  increase  begins  to  become  more 
severe.  (This  aspect  is  beginning  to  get  more  attention  in 
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systems  engineering  with  LSI  chips.)  Most  semiconductor  com- 
panies will  send  the  chips  overseas  to  be  packaged  and  assembled 
into  a product.  The  mounted  chip  is  inspected  for  good  con- 
nections. The  industry  average  yield  of  good  mountings  is  about 
80-90%  of  the  number  of  chips  that  pass  wafer  yield.  This 
yield  is  called  the  packaging  yield.  Returning  to  the  example, 
that  moans  80-90  good  chips  (200  mil  x 200  mil)  from  the  4- 
inch  wafer  at  this  point.  A cap  of  ceramic  or  plastic  is  in- 
stalled on  these  good  packages.  For  high  reliability  uses, 
the  cap  is  hermetically  sealed.  The  hermetic  seal  is  the  pri- 
mary reason  given  for  the  more  expensive  price,  by  a factor 
of  2-3  over  commercial  chips,  of  military  temperature  spec 
Dip's.  For  other  uses  the  cap  is  molded  on.  The  capped 
package  is  extensively  tested  at  this  point  by  automatic 
testing  equipment.  The  ratio  of  good  chips  to  the  total  in 
this  final  test  yield  is  80-90%.  Continuing  the  example, 
that  means  about  64-81  good  chips  (200  mil  x 200  mil)  from  a 
possible  of  300  from  a 4-inch  wafer. 

The  reader  should  at  this  point  reflect  on  the 
philosophy  for  designing  large  systems  in  this  report.  As 
chips  become  larger  and  more  complex,  the  design  of  this  final 
test  can  approach  that  of  the  logic  design  of  the  chip  itself, 
i.e.,  this  non-recurring  cost  of  final  test  design  can  be  on 
the  order  of  tens  of  thousands  of  dollars,  if  not  into  the 
hundreds  of  thousands  of  dollars.  Even  if  computer-aided- 
design  and  final  mask  and  diffusion  customizing  can  reduce 
the  non-recurring  logic  design  cost,  a non-recurring  final 
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Lest  design  cost  must  stil 1 be  incurred  tor  every  peculiar 
logic  design  conceived  of.  Computer  generated  tests  can 
aid  this  process.  An  obvious  cost  advantage  could  be  had 
by  the  user  if  this  large  test  design  non-recurring  cost 
is  spread  over  as  many  other  users  as  possible. 

Because  of  the  labor  intensiveness  of  packaging,  and  its 
cost  as  an  increasing  function  of  pin  count,  some  forms  of 
packaging  are  being  developed,  other  than  the  DIP,  which  lend 
themselves  to  easier  productizing  (interconnecting)  from  a 
chip  set.  One  which  appears  in  a couple  of  different  forms 
is  called  the  chip  carrier.  Using  a completely  automated 
procedure,  the  LSI  chip  is  suspended  and  encapsulated  in  a pin- 
less package.  The  leads  are  bonded  to  the  chip  and  joined 
to  only  a solder  point  on  the  edge  of  the  carrier. 

Up  to  this  point  what  has  been  discussed  is  the  manufac- 
turing process  of  logic  design  of  packaged  chips  for  a micro- 
processor/microcomputer device.  In  summary,  the  non-recurring 
manufacturing  cost  of  logic  design  is  from  the  tens  of  thou- 
sands of  dollars  into  the  few  millions  of  dollars.  The  same 
magnitudes  are  true  for  the  non-recurring  cost  of  logic  design 
testing  procedures.  The  recurring  costs  of  packaged  chip 
manufacturing  have  followed  the  trend  in  Figure  P^-l)  and  are 
currently  between  about  .01-. 1C  per  active  element  group.  That 
means  that  for  a microprocessor  chip  on  the  level  of  complexity 
of  the  Intel  8080A,  about  4,000  gates  per  chip,  the  recurring 
cost  of  manufacturing  for  a sustained  run  is  between  about 

$.40  to  $4.00  per  chip  with  a selling  price  around  $15-20.00.  I 

A military  temperature  spec  chip  based  on  a sampling  of  price 
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lists  is  about  2-3  times  that  price.  A chip  of  the  complexity 
of  the  16  bit  word  length  TT  99*10,  a recently  announced  sinqle 
chip  microcomputer  of  about  10,000  gates,  including  1-2,000 
memory  bits  and  I/O  points,  would  have  a recurring  manufac- 
turing cost  of  up  to  about  $10.00  per  chip.  However,  the 
selling  price,  as  initially  guessed  by  competitors,  is  at 
about  $500.00  for  the  TI  9940  because  Texas  Instruments  will 
still  be  amortizing  the  non-recurring  costs  and  still  be  coming 
down  the  experience  curve. 

The  area  to  be  addressed  now  is  the  process  of  going  from 
an  LSI  chip  set  to  a finished  microcomputer  product.  This 
process  is  best  conceived  of  as  involving  three  stages,  inter- 
connecting the  packaged  chips  to  a board,  interconnecting  the 
boards  to  accommodate  for  power,  signal,  and  ground,  and 
finally,  interconnecting  boards  into  a product  case  like  an 
ARINC  Air  Transport  Rack  (ATR)  or  a Naval  Standard  Elec- 
tronics Module  (SEM2A) . There  is  a wide  variety  of  methods 
to  accomplish  each  of  these  steps  and  it  is  probably  fair  to 
say  that  these  steps  are  not  as  amenable  to  as  rapid  a pace  of 
technological  change  in  manufacturing  technology  as  is  the 
fabrication  of  the  packaged  LSI  chip.  Again,  it  is  volume 
that  will  determine  the  amount  of  automation  that  will  exist 
in  the  manufacturing  process.  Systems  engineering  trade-offs 
are  made  between  performance,  and  reliability/maintainability 
which  impact  the  manufacturing  technology  of  productizing 
from  chip  sets,  rather  than  the  manufacturing  technology  im- 
pacting the  systems  engineering  as  with  the  chip  making  process. 
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The  non-recurr inq  cost  of  product  desiqn  from  chip  sets 
is  on  the  order  of  thousands  of  dollars  into  the  few  hundreds 
of  thousands  of  dollars  but  again,  possibly  into  the  few 
millions, of  dollars  for  some  corporate  strategy  intertwined 
items  like  the  first  programmable  calculators  or  militarized 
processors  and  computers  like  the  AYK30,  LSIllM,  PDP11/34M, 
AYK14,  and  ROLtl  products. 

The  parameter  for  recurring  cost  estimation  and  also  for 
reliability /maintainability  measurements  when  productizing 
(interconnecting)  an  existing  LSI  chip  set  is  the  number  of 
connections  or  contacts  that  have  to  be  made  between  chips 
and  supporting  active  element  groups  like  power,  ground,  and 
signal  connections  within  the  product.  Although  the  contri- 
buting failure  mechanisms  of  LSI  chips  to  the  product  are 
being  explored,  it  is  the  interconnects  that  are  most  signifi- 
cant in  the  failures  of  a product  and  that  may  reflect  the 
reliability  overkill  of  the  LSI  chip. 

These  recurring  costs  for  a sustained  production  run 
range  from  5C  to  IOC  per  connection  and  slightly  more  depend- 
ing on  the  interconnect  method  used,  production  volume,  and 
automation  level  of  manufacturing.  A few  of  these  inter- 
connect methods  will  be  described.  Following  this  will  be  a 
description  of  three  techniques  that  go  directly  from  chip 
carriers  (vice  packaged  chips)  to  product.  When  projecting 
to  a VSTOL  program  with  the  concept  definition  and  validation 
occurring  in  about  the  1981-1985  time  period,  it  will  probably 
be  one  of  these  three  techniques  that  will  end  up  as  the 
interconnect  technique. 
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Interconnection  of  chips  in  computers  in  the  early  1970 's 
was  accomplished  with  point-to-point  wiring  of  chips  mounted 
on  molded  plastic  blocks  throughout  the  system.  This  is  labor 
intensive  but  provides  the  ultimate  in  flexibility  and  would 
be  now  used  primarily  for  breadboarding  of  prototypes  or  low 
volume  products  that  don't  justify  the  capital  expense  of 
automated  fabrication  machinery.  More  common  today  is  the  use 
of  printed  circuit  boards  (PCB's),  which  have  solder  runs  to 
provide  the  means  of  current  conduction.  The  DIP's  are  pressed 
manually  or  automatically  into  female  connectors  aligned  on  the 
PCB . These  boards,  called  daughter  boards,  still  must  be  con- 
nected into  a backplane,  called  a mother  board  as  in  Figure 
(A—  2 ) from  reference  (A-l) . 

Piyure  A-2 


Originally,  the  mother  boards  were  metal  backplanes  and  had 
rows  of  female  post  connectors  into  which  male  edge  connectors 
on  the  daughter  boards  were  plugged.  Posts  on  the  mother 
board  served  as  leads  into  which  hand  wire-wrapping  (more  than 
1(K  per  connection)  or  automated  wire  wrapping  (about  1(K  per 
connection)  were  accomplished  on  the  reverse  side  of  the  back- 
plane. The  wire  wrapping  provides  flexibility  in  that  the 
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board  can  be  rowrapped  if  a daughter  board  is  updated.  In  very 
large  quantity  designs  where  flexibility  is  not  so  important, 
a multilayer  printed  circuit  epoxy-glass  or  fabric  mother  board 
is  now  used.  The  printed  circuit  daughter  boards,  often  two- 
sided,  are  pressed  into  the  edge  connectors  on  the  mother 
board,  also  often  two-sided.  The  printed  circuits  on  the 
multilayered  mother  board  provide  the  interconnects  via  posts 
of  selected  lengths  that  run  through  the  mother  board  layers. 

Some  mother  boards  still  retain  a few  posts  for  wire  wrapping 
of  power,  signal,  and  ground  points.  Others  don't,  relying 
instead  on  flat-wire  edge  connectors.  The  cost  per  connection 
on  the  multilayer  printed  mother  boards  is  about  5-8C,  depend- 
ing on  several  things  such  as  the  number  of  layers,  remaining 
wire  wraps,  etc. 

The  number  of  interconnects  per  edge  connection  on  the 
PCB  has  increased  from  a few  to  several  dozen  as  the  level  of 
chip  integration  has  increased.  Hence,  the  amount  of  force 
required  to  insert  a daughter  board  into  a mother  board  has 
increased  considerably.  This  has  led  to  Zero  Insertion  Force 
(ZIF)  connectors.  There  are  several  ZIF  designs.  They  re- 
quire no  force  for  insertion  because  all  the  female  connectors 
are  initially  free  of  resistance.  Once  the  PCB  board  is  in 
place,  then  a mechanical  action  like  a lever  or  machine  screw 
is  actuated  to  close  all  the  female  contacts  simultaneously. 

The  latest  form  of  the  ZIF  connector  is  to  dispense  with 
the  mother  board  idea  all  together  and  stack  two-sided  daughter 
boards  via  ZIF  connectors  that  themselves  act  as  active  elec- 

I 

tronic  elements  (Figure  A-3)  . 
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ZIF  CONNECTORS 
Figure  A- 3 


The  trend,  as  can  be  seen  by  the  ZIP  interconnect  technol- 
ogy, is  toward  making  the  interconnects  themselves  active 
electronic  elements.  Referring  back  to  the  chip  carrier  con- 
cept, in  some  cases  the  chip  carriers  are  automatically  placed 
on  cold  solder  points,  which  themselves  have  been  automatical ly 
placed  on  a ceramic  layered  PCD.  The  entire  arrangement  is 
refluxed  in  a kiln.  The  chips  line  up  with  the  solder  points 
as  the  solder  cools.  Figure (A-4)  shows  one  board  of  SEM2A 
size  module  productized  in  this  manner.  Up  to  six  of  these 
boards  would  bo  joined  with  ZIP  connectors  in  the  SEM2A  module. 

Another  type  of  chip  carrier  package  stacks  several  carriers 
together  with  the  stacking  frame  acting  as  active  electronic 
elements  in  the  overall  product  (Figure  A-5) . 

These  are  two  of  the  more  advanced  chip  carrier  concepts 
used  to  create  a product  out  of  a chip  set.  The  cost  per 
connection  for  interconnecting  the  chip  carriers  as  described 
above  is  projected  at  slightly  more  than  1(K  per  connection  in 
volume . 

Another,  albeit  somewhat  more  exotic,  technique  which  has 
particular  meaning  with  regards  to  optical  fiber  data  trans- 
mission technology  and  avionics,  is  the  flexible  circuit.  Up 
until  now,  each  of  the  interconnect  arrangements  described 
was  still  somewhat  conventional  in  that  chips  were  connected 
to  boards,  boards  were  interconnected,  and  these  were  placed 
into  a card  cage  with  a metallic  ATR  or  SEM2A  sized  box  and  a 
control  panel.  The  flexible  circuit  idea  dispenses  with  the 
idea  of  boxing  chips  on  boards.  It  involves  taking  several 
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chip  packages,  or  as  is  more  likely  by  19R5,  several  chip 
carriers,  each  with  its  own  convection  cooling  vanes,  and 
interconnecting  them  to  a flat,  flexible  bundle  of  wire,  or 
a flat  fiber  optic  bundle  (Figure  A-6).  (The  arrangement 
would  look  very  much  like  the  sugar  drop  candies  affixed  to 
paper  tape,  popular  with  children  a generation  or  two  ago.) 

The  flexible  circuit  would  weave  its  way  through  the  aircraft 
airframe  interconnecting  with  sensors,  power,  and  ground  as 
appropriate  (in  much  the  same  way  as  human  nerve  fibers  weave 
their  way  through  the  body)  with  no  metallic  housing  (ATR  or 
SEM2A)  required.  Servicing  would  not  require  "neurosurgery" 
level  expertise  in  that  built-in-test  (BIT)  programs  could 
isolate  out  sections  of  the  flexible  strip  for  replacement 
via  snap  connectors  located  every  so  often.  All  that  would 
have  to  be  known  for  service  would  be  an  hierarchical  level 
model  of  the  data  flow  within  the  aircraft,  much  like  the  one 
described  in  this  report,  since  the  BIT  would  isolate  to  a 
section  of  flexible  circuit. 

The  two  former  chip  carrier  systems  are  still  slightly 
above  the  100  per  connection  figure.  The  latter  flexible  cir- 
cuit idea  is  only  in  the  conceptual  stage  and  no  cost  inform- 
ation is  available.  The  key  to  the  ability  of  all  three  of 
these  advanced  techniques  to  be  able  to  compote  cost-wise  with 
existing  interconnect  techniques  is  in  whether  or  not  demand 
for  them  will  be  of  such  a volume  that  their  automated  manu- 
facturing technology  investment  is  justified.  Based  on  the 
military'  computer  system  numbers  generated  in  this  report,  it 
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is  doubtful  whether  the  military  alone  could  foster  the  neces- 
sary volume.  Rather,  as  postulated  throughout  this  report,  the 
military  will  have  to  get  in  on  the  commercial  market. 

A good  example  of  how  the  military  spec  is  already  adjust- 
ing to  commercial  market  forces  is  the  coating  used  on  connec- 
tions to  combat  corrosion  on  interconnect  surfaces.  Gold 
plate  over  nickel  is  used.  The  mil-spec  was  50p  in.  gold  over 
100p  in  nickel  but  was  lowered  to  30p  in  gold  over  50p  in 
nickel.  The  latter  is  the  thickness  already  used  in  certain 
types  of  commercial  computers.  Besides  corrosion,  temperature 
extremes,  large  vibrations,  excessive  moisture  and  radiation 
are  also  considered,  in  view  of  the  military  specification 
structure,  as  requiring  special  handling  for  a military  compu- 
ter. The  totality  of  these  areas  when  demonstrated  in  a mil 
spec  device  or  complete  computer  creates  about  a factor  of  2-3 
more  in  the  price  of  a military  computer  when  compared  to  its 
commercial  counterpart.  Continuance  of  that  factor  is  ques- 
tionable as  basic  devices  and  products  find  commercial  use 
in  high  reliability  areas  like  steel  furnace  control,  nuclear 
power  plant  control,  automobiles,  general  aviation,  etc. 

B . SOFTWARE 

There  are  three  discernible  parts  to  the  avionics  software 
cost  issue,  and  the  software  cost-estimating  problem.  The 
first  part  is  the  cost  associated  with  the  applications  soft- 
ware creation.  In  avionics  this  is  the  Operational  Flight 
Program  (OFP) . The  second  part  is  the  software  development 
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and  support  tools  used  for  creation  of  the  applications  soft- 
ware. These  are  the  compilers,  debuggers,  editors,  etc.  The 
third  part  is  the  aircraft  systems  simulators,  the  mock  ups 
which  are  used  to  simulate  an  aircraft  in  flight,  to  test  out 
the  OFP . To  place  the  software  cost  issue  in  perspective, 
interviews  with  industry  indicate  that  as  much  as  95%  of  soft- 
ware cost  is  in  the  development  and  support  tools  and  systems 
simulators.  Literature  search  indicates  that  cost  estimating 
for  the  estimated  remaining  5%  is  more  structured  with  regards 
to  parametric,  or  top  down,  techniques  and  established  data 
bases.  The  cost  estimating  of  development  and  support  tools 
and  simulator  systems  is  left  to  the  engineering,  or  bottom 
up  method,  and  is  dependent  on  the  decision  at  hand,  the 
actual  computer  system  under  review,  and  the  systems  already 
in  place. 

The  systems  simulators  are  not  considered  as  a differen- 
tial cost  element  in  this  report  as  they  are  created  on  param- 
etric characteristics  of  the  aircraft  and  the  actual  computer 
architecture  of  the  avionics  system  is  transparent  to  them. 

The  differential  cost  elements  with  respect  to  the  avionics 
computer  system  architecture  are  the  software  development  and 
support  systems  and  the  applications  software  creation. 

These  two  cost  elements  are  important  to  the  economic  analysis 
of  this  report  because  the  worth  of  a standard  computer  family 
is  most  often  argued  for  in  light  of  the  savings  generated  by 
software  commonality  across  several  applications.  The  software 
costing  in  this  report  will  be  framed  around  exploring  the 


validity  of  that  argument  in  light  of  possible  rates  of  growth 
of  use  of  a standard  computer  family,  possible  rates  of  growth 
of  technology  embodied  in  computing  devices  in  the  commercial 
world,  and  the  effects  on  aircraft  airframe  cost  of  the  avion- 
ics computing  system. 

Of  the  two  differential  software  cost  areas,  OFP  creation, 
and  development  and  support  tools,  generalization  of  the  cost 
issues  and  methods  of  the  former  will  be  addressed  first  (a 
costing  method  used  in  contracting  and  a parametric  technique 
will  be  described  from  the  literature).  The  latter  will  then 
be  addressed  based  on  trends  discerned  by  this  author  from  the 
literature. 

Aircraft  contracts  with  hardware  and  software  procurement 
bundled  together  cost  the  applications  software  development 
as  a percentage  of  the  airframe  engineering  full  scale  devel- 
opment man-hours.  The  percentage  is  a negotiated  figure 
based  on  the  corporate  history  of  both  the  buyer  and  seller 
and  may  or  may  not  include  the  cost  of  the  development  and 
support  tools,  and  systems  simulators.  Because  corporate 
costing  history  is  proprietary  and  because  this  report  is 
meant  to  generate  some  independent  estimates,  a parametric 
technique  was  used,  best  described  by  reference  (A2) . This 
technique  will  be  paraphrased  for  the  reader.  In  the  process 
of  doing  so  it  will  be  highlighted  with  some  additional  current 
thoughts  from  the  literature  on  the  applications  software  life 
cycle  and  management.  An  annotated  bibliography  is  also  in- 
cluded at  the  end  of  this  report  for  the  reader  specifically 
interested  in  this  area. 
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The  parametric  technique  of  reference  (A2 ) is  based,  as 
most  are,  on  the  parameter  of  software  proqram  size  as 
measured  by  number  of  source  or  object  instructions.  Often 
the  instruction  count  is  weighted  by  the  degree  of  difficulty 
or  complexity  inherent  in  the  creation  of  the  instruction 
type  and  whether  the  programming  routine  is  old  or  new  (A3) . 

In  the  technique  used  for  this  report  an  estimating  relation- 
ship coefficient  will  embody  these  ideas  of  degree  of  diffi- 
culty and  old  or  new  for  a certain  class  of  software  programs. 

Cost  is  generally  expressed  in  man-months  of  effort  vice 
dollars  so  that  an  individual  software  vendor's  cost  per  man- 
month  can  be  applied  when  the  technique  is  used  for  planning, 
budgeting,  or  contract  negotiations. 

After  sizing  the  software  in  terms  of  man-months  for 
development,  the  next  step  in  the  estimating  technique  is  to 
time  phase  the  man-months  over  the  calendar  time  of  the  soft- 
ware development  project.  The  idea  behind  this  phasing  is  to 
generate  a man-loading  curve  (man-months  per  month)  for  pro- 
ject management.  Once  this  curve  has  been  generated,  incre- 
ments of  man-loading  resource  are  spread  across  the  various 
project  activities  such  as  documentation,  project  management, 
programming,  etc. 

The  entire  process  can  be  framed  using  the  figure  (A-7) 
from  reference  (A2) . The  technique  begins  by  using  the  follow- 
ing relationship  to  estimate  man-months  for  applications  soft- 
ware development  effort. 


MM 
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where 


man-months  of  development  effort 

a coefficient  estimated  from  a data  base  of  like  projects 


MM 


C 


I 


o,s 


P 

f . 


the  count  of  source  or  object  instructions  in  the 
applications  software 

a power  estimated  from  the  data  base  of  like  projects 

multiplicative  factors  that  come  from  a stratification 
of  the  data  into  groups  such  as;  developed  on  host 
computer  vs.  target  computer,  developed  on  a time 
share  system  vs.  a batch  system,  etc. 


As  seen  from  figure(A-7),  development  is  only  part  of  the  appli 
cations  software  life  cycle.  It  has  come  to  be  sub-divided 
itself  into  three  phases;  analysis  and  design,  code  and  debug, 
and  module  and  systems  test  and  integration.  Literature  search 
and  interviews  support  the  conventional  wisdom  that  the  split 
of  effort  between  these  three  phases  of  development,  i.e.,  the 
man-loading  split,  is  40%,  20%,  40%  respectively  (A4) . 

Once  the  number  MM  has  been  estimated,  the  technique  takes 
the  following  quotient  to  determine  the  total  man-months  of 
effort  in  the  applications  software  life  cycle,  i.e.,  the  total 
area  under  the  curve  of  figure  (A-7). 

v - ^ 

K 0759 


K - total  man-months  of  effort  for  life  cycle  of  applications 
program 

The  technique  then  describes  the  curve  by 


where 
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tQ  = I / (99.25+2.33IO  ) 

Y - man-months/month 

tD  - natural  development  time  for  an  applications  program  of 
I object  instructions 

2 

The  major  point  of  the  technique  is  that  (K/t^  ) is  a 
constant  based  on  instruction  count,  and  that  it  is  not  possi- 
ble to  compress  the  natural  development  time  by  adding  man- 
months  of  effort.  Rather  it  is  hypothesized,  supported  by 
independent  sources  (A5,A6,A7),  that  there  exists  a natural 
time  and  man-loading  curve  for  a particular  sized  program.  In 
the  words  of  Brooks  in  his  classic  essay  "The  Mythical  Man- 
Month",  adding  man-months  of  effort  to  an  applications  soft- 
ware development  project  which  is  off  schedule  makes  it  later, 
particularly  if  as  pointed  out  in  (A3) , it  is  added  late  and 
tentatively.  Preliminary  work  by  others  shows  that  the  dis- 
tribution of  K,  the  total  man-months  of  effort,  by  a 39%K  to 
development,  55%K  to  transition  to  the  user,  and  5*K  in  steady 
state  maintenance  is  reasonable  within  a few  percentage  points 
( A9)  . 

Reasons  for  the  shape  of  the  man-loading  curve  in  figure 
(A-7)can  be  found  in  another  reference  (A10)  which  reports  that 
the  error  profile  of  an  applications  program  can  be  character- 
ized by  the  saw-tooth  of  figure  ( A—  8 ) . 

The  cause  of  this  saw-tooth  effect  is  intuitively  pleasing 
and  plausible.  When  a user  begins  use  of  the  applications 
software  during  transition,  it  is  put  through  a wider  range  of 
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data,  on  the  target  machine,  and  possibly  i more  taxing 


environment  than  that  of  the  development  lab.  hugs  are  dis- 
covered and  worked  out  that  weren't  discovered  in  the  more 
benign  environment  of  the  development  lab. 

This  technique  of  reference  IA2)  , paraphrased  above,  will 
be  used  to  cost  the  navigation  and  ballistics  portion  of  the 
VSTOL  OFP  analyzed  in  the  first  part  of  this  report.  It  will 
also  be  used  to  address  the  issue  of  development  and  support 
tool  cost  and  software  maintenance  cost.  A literature  search 
in  this  other  area  of  software  cost  impressed  this  author  of 
the  point  that  as  with  the  minicomputer,  the  microcomputer  is 
undergoing  a burgeoning  of  software  development  and  support 
tools.  Several  forms  of  these  tools  are  available. 

One  approach  is  to  purchase  outright  a software  develop- 
ment system  targeted  for  the  particular  microcomputer  device 
for  each  applications  programmer.  These  systems  are  available 
from  both  the  parent  company  and  the  software  tools  houses 
and  require  the  initial  capital  investment  and  training  work 
up.  Although  the  systems  vary  as  to  compatibility  and  cost, 
a development  system  with  CRT,  key  board,  a higher  order 
language  (HOL)  like  FORTRAN,  PLM,  or  PASCAL,  a set  of  pro- 
gramming aids,  and  a read  only  memory  (ROM)  programmer  can  be 
had  in  the  $25,000  range. 

Another  approach  is  to  lease  time  from  the  increasing  num- 
ber of  microcomputing  development  commercial  time  share  sys- 
tems capable  of  handling  all  of  the  various  device  types. 

These  firms  make  the  capital  investment  in  the  development 
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and  support  system  tools  rind  then  lease  the  time,  a process 
modeled  by  the  same  S • N ^ CNR  + CR-N  inequality  of  the  first 
part  of  this  report.  A current  quoted  fiqurc  is  $1,000  per 
month  for  lease  of  one  terminal  that  provides  any  one  of 
several  HOL's  for  any  one  of  several  microprocessor/micro- 
computor  devices.  The  terminal  would  have  a CRT,  and  a basic 
set  of  programming  aids. 

A third  approach  is  to  buy  outright  a development  system 
capable  of  handling  several  different  microprocessor/micro- 
computer devices.  Although  no  quotes  were  available,  these 
systems  would  start  at  $100,000. 

A final  approach  considered  is  to  create  the  development 
and  support  tools  for  the  target  microcomputing  devices  and 
the  input/output  structure  for  each  application  to  run  on  a 
main  frame  host  machine.  This  would  be  in  the  form  of  com- 
pilers, code  generators,  assemblers,  debuggers,  linkers, 
loaders,  etc.  The  data  generated  by  the  Computer  Family 
Architecture  report  will  be  used  in  this  report  in  an  order 
of  magnitude  way  to  address  the  costing  issues  of  this  method 
of  supporting  software  with  respect  to  the  others.  As  an 
example  of  the  magnitudes  involved  in  this  method,  the  CFA 
report  estimated  about  $4.9M  for  a CMS2  compiler  for  the  CFA 
candidate  machine. 
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